--- id: KB-PS-001 url: https://app.codecontract.io/help/getting-started/what-is-code-contract idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-002, KB-TL-001, KB-CO-001, KB-SC-001] citadoPor: [KB-PS-002, KB-TL-001, KB-CO-001, KB-SC-001, KB-PR-001, KB-ET-001, KB-CD-001, KB-MA-001, KB-PS-003, KB-PS-004] enLaApp: https://app.codecontract.io/dashboard --- # What Code Contract is and what it is for _Three modules on one foundation: request documents, sign them and certify them as evidence._ **Responde a:** what is Code Contract · what is Code Contract used for · platform to request documents from suppliers · alternative to chasing documents by email · document management software with signature and traceability Code Contract is a platform for handling the documents that come in and out of your company whenever somebody else is involved: a supplier who owes you a certificate, a client who has to sign a contract, an inspector who in two years' time will ask you to prove you held a document on a specific date. **En corto** - Three modules — Trackline, Consigne and SmartCheck — solving three different problems, usable separately. - They share one foundation: your team, your contacts, your folders and the record of who did what. - Everything that happens is dated and logged, which is what turns a file into evidence. - The people who send you documents or sign them do not need an account. ## The problem it solves Most companies do all of this with three tools that do not talk to each other: email to ask, a signing service to sign, and a shared folder to store. It works until somebody asks "did the supplier ever send that certificate?" and you have to dig through an inbox — or until you have to prove to a third party that a document existed on a given date, and all you have is a file with a modification date anyone could change. Code Contract puts the three together in one place and, more importantly, leaves a trail of every step: who asked for what, when they were chased, when they replied, what they sent and what was done with it. ## The three modules **Three independent modules on a shared foundation** — Each module solves a different problem, but all three rest on the same team, contacts, folders and traceability. | Module | What it does | A typical case | | --- | --- | --- | | Trackline | Requests documents and data from other people, chases them if they go quiet, reads what arrives and organises the case into phases | Onboarding a supplier by asking for six different documents | | Consigne | Sends a document for signature, tracks who has signed and produces a signed PDF with its legal evidence | Getting a new hire to sign their contract before they start | | SmartCheck | Seals whatever you give it with a date that can be demonstrated and can no longer be altered | Keeping quality records for next year's audit | _You do not have to use all three. Many people start with one and add the others when they need them._ ## How the pieces fit The difference between the three is who acts. In Trackline the ball is in someone else's court: you ask and wait. Consigne also goes outward, but what you are waiting for is a signature, not a file. In SmartCheck nobody else is involved: you upload something of yours and leave it sealed. > [!NOTE] > If you have to pick a starting point, start with Trackline: it removes the most manual work from day one, because chasing documents is what eats the most time. ## What people outside your company need Nothing. No account, no password, nothing to install. Each person gets their own link, opens it on a phone or a computer, does their bit — upload a file, fill in some data, sign — and that is it. That is deliberate: most of the time the person who owes you a document is not going to sign up for a tool they have never heard of. ## Frequently asked questions **Do I have to use all three modules?** No. They are independent and can be bought and used separately. They share the platform foundation, so if you add another one later, your contacts, folders and team are already there. **Does the person I ask for a document need an account?** No. They get their own link by email, SMS or WhatsApp and upload what you asked for without registering anywhere. **How is this different from a shared folder?** A folder stores files. Code Contract also asks for what is missing, chases it if it does not arrive, reads what does arrive, and records every step with a date. When someone asks what happened, there is a logged answer instead of a reconstruction from emails. **What happens if I stop using the platform?** Documents signed with Consigne are ordinary PDFs with the signature and seal inside: they validate in any reader without depending on us. And you can export your data whenever you want. **Which languages does it support?** The product covers Spanish, English, French and Portuguese. Notices sent to your contacts go out in their own language. ## Ejemplos **An accounting firm onboards a new client, needs six documents from them, needs the engagement letter signed, and needs to keep it all in case the tax authority asks four years from now.** - Trackline requests the six documents and chases only what is missing - Consigne sends the engagement letter for signature - SmartCheck closes the case with a demonstrable date → A complete case file, with the signature proven and a date that can be demonstrated to a third party without relying on anyone's word. **A contractor must prove to their client that every subcontractor was current on the day they entered the site.** - Trackline requests each subcontractor's documentation and warns about expiries - SmartCheck seals each submission with its date → When the client asks about a specific date, the answer uses what applied that day rather than today. **A firm emails contracts for signature and never knows who has signed and who has not.** - Consigne sends each contract and shows each signer's status - Reminders go out on their own until it is signed → What is outstanding is visible at a glance, without writing to ask whether anyone received it. **A company receives a hundred invoices a month and somebody keys them in one by one.** - The data is read from the document and stays attached to it - Whatever the AI is unsure about is flagged for review → Keying becomes reviewing, and each figure stays tied to the document it came from. **A client calls an audit and two years of files scattered across folders and inboxes must be gathered.** - Everything requested, signed and sealed lives in one place - Only what is relevant is shared, with a trail of who saw it → Preparation goes from weeks to an afternoon, and nothing extra is handed over. **A company wants to start with the most urgent thing rather than a six-month project.** - One module is used for one real process - The other two are added when they are needed → Something is running in week one instead of a plan nobody has tried. --- --- id: KB-PS-002 url: https://app.codecontract.io/help/getting-started/folders-projects-documents-and-data idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-001, KB-TL-001] citadoPor: [KB-PS-001, KB-TL-001, KB-SC-001, KB-GL-001] enLaApp: https://app.codecontract.io/documents --- # How everything is organised: folders, projects, documents and data _The four levels information is organised into, identical across all three modules._ **Responde a:** how do I organise documents in Code Contract · difference between folder and project · where are documents stored · folder structure for document management Whichever module you are in, information is always organised into the same four levels. Learning it once covers all three, and getting it right from the start avoids the most common mess: ending up with forty loose folders and no idea what is in any of them. **En corto** - Folder → Project → Document → Data, in that order, across all three modules. - The folder is optional and exists so that YOU can find things. - The project is mandatory and is the unit that gets shared, certified and exported. - Data is filled in by automatic reading when the document arrives, and you confirm it. **The four levels** — Each level lives inside the one above. Only the folder is optional; every document belongs to exactly one project. ## Folder: for tidiness It works like a folder on your computer. You can nest folders inside folders and build whatever structure suits you: by year, by client, by site, by department. It is optional: anything you do not file stays at the root and works perfectly well. > [!NOTE] > Advice from people who have already set this up: do not go beyond two or three levels of folders. Past that, browsing to find something costs more than searching for it. ## Project: the level that really matters A project groups everything to do with one matter: onboarding one specific supplier, one specific rental contract, one specific quarter's audit. It does not nest — there are no projects inside projects — and it belongs to one module: a project is a Trackline, a Consigne or a SmartCheck project, not all three at once. It matters because it is the unit the platform works with: what gets shared with a third party is a project, what gets certified is a project, what gets exported is a project. Every document belongs to exactly one. ## Document or evidence: the file This is the file itself. It changes name by module because its role changes: in Trackline it is what somebody else sends you, in Consigne it is what gets signed, in SmartCheck it is what you certify. Underneath it is the same thing: a file with its date, its author and its record. ## Data: what is inside the document These are the specific fields that matter from that document: invoice number, due date, amount, company name. Automatic reading fills them in when the document arrives, and you review and confirm. They are what later lets you search for "every invoice over €5,000" instead of opening files one by one. ## Frequently asked questions **Can I move a document from one project to another?** Yes, while the case is open. What you cannot do is leave it with no project: every document belongs to one. **Can I put a project inside another project?** No. Projects do not nest, by design. If you need to group several, use a folder — that is exactly what folders are for. **Can one project belong to two modules?** No. Each project belongs to one module. If a single matter needs documents requested and then signed, you will have one Trackline project and one Consigne project, and you can keep both in the same folder. **What if I never create a folder?** Nothing bad. Everything sits at the root of the module and works the same. Folders are for your convenience, not a requirement. ## Ejemplos **A letting agency manages seasonal rentals for 2026.** - Creates the folder "Rentals" and "Summer 2026" inside it - Each booking is a project: "City Centre Flat — Ruiz Family" - Inside the project sit the ID document, the signed contract and the deposit receipt - Each document yields its data: check-in and check-out dates, deposit amount → When claiming the deposit, the whole project is shared at once, with its documents and its data, instead of hunting for three files in an inbox. **An advisory firm files everything by client and cannot find the documents for one particular year.** - The folder is the client and the project is the year - Each document hangs from the year it belongs to → You open the year and everything for it is there, without filtering by upload date. **A contractor mixes three different jobs for the same client in one folder.** - Each job is a project with its own name - The folder groups the client, not the work → One job can be closed without touching the other two. **A team is unsure whether to look for a figure in the document or in a record.** - Data is extracted from the document and hangs from it - The document stays the source and the figure is its reading → Any doubt leads back to the original document straight from the figure itself. **A company wants to search by amount rather than by file name.** - Extracted data can be queried as fields - The document is found by what it says, not what it was called → Finding stops depending on somebody naming the file well. **Someone creates a folder per document and the structure becomes unmanageable.** - The folder groups; the project is the unit of work - The document lives inside the project, not in a folder of its own → The structure stops growing with every file that arrives. --- --- id: KB-PS-006 url: https://app.codecontract.io/help/getting-started/bringing-in-the-documents-you-already-have idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-ET-004] citadoPor: [KB-TD-011, KB-DI-017] --- # Bringing in what you already have _What to migrate from the old archive and, above all, what not to._ **Responde a:** migrate documents from a shared folder · upload the historical archive · digitise the paper archive · start with the documents i already have The question comes up on day one: "what about everything we already have?". The answer that works is uncomfortable but true: almost none of it. Migrating twenty years of archive is a project that rarely finishes, and while it runs nobody is using the tool for anything. ## What to bring, in order 1. **What is current** — The insurance, certificates and contracts that apply now. That is what you will consult. 2. **What expires soon** — Because you want to be warned, and for that it has to be inside. 3. **What you get asked for often** — If someone asks for it three times a month, it belongs here. 4. **The rest, when needed** — Uploaded the day someone looks for it. Most of it is never looked for. ## What not to bring - Documents about people who have left, absent a retention obligation. - Copies of identity documents you have no reason to keep. - Old versions where you already hold the current one, unless they prove something. - All the email. Email is not an archive. > [!IMPORTANT] > A migration is the best moment to stop keeping what you should not hold. If you are about to move hundreds of candidate ID documents from eight years ago, the right question is not how to move them: it is whether to keep them. > [!WARNING] > Bringing a messy archive relocates it, it does not tidy it. And it clutters searches exactly while you are learning to use them. > [!NOTE] > A rule that works: if nobody has searched for it in six months, it did not need bringing. Starting with what is current and letting need pull the rest is right nearly every time. **What about paper?** Scan what gets consulted. Digitising the whole archive rarely finishes. **Can whole folders be uploaded?** Yes, with their structure. **Are old documents read on upload?** Yes, if reading is enabled for that type. ## Ejemplos **A company plans to scan twelve years of archive before using anything.** - Uploads only current documentation for its 60 active suppliers - Leaves the rest where it is → It is working in three days instead of three months, and six months on only nine old documents have had to be retrieved. **The whole archive is uploaded and finding anything becomes harder than before.** - Uploads only what is current and actually consulted - Leaves the history where it is, and locatable → What is looked for daily surfaces without noise around it. **Nobody knows which documents in the archive are still valid.** - Records the expiry when each document is uploaded → The move itself leaves the archive reviewed. **The start is put on hold until migration finishes.** - Starts working with new material from day one - Uploads old material only when someone needs it → Migration stops being a precondition for starting. **Old documents are uploaded without knowing which supplier they belong to.** - Attaches each document to its file as it is uploaded → What is moved is usable rather than a pile of files. **Months later a document that was not migrated is needed.** - Records where the historical archive sits → Retrieving it is a query rather than a blind search. --- --- id: KB-PS-007 url: https://app.codecontract.io/help/getting-started/what-your-suppliers-will-ask-you idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-GL-002, KB-CO-019] citadoPor: [KB-CO-015] --- # What your suppliers will ask you _The five questions that arrive with your first notice, with their answers._ **Responde a:** the supplier asks whether this is safe · what do i tell a client who distrusts the link · do my suppliers have to register · how do i explain electronic signature to a supplier The first time you send a request, people reply with questions rather than documents. It is always the same five, and having the answers ready stops the process stalling right at the start. ## 1. "Is this legitimate?" It is the right question and worth welcoming. The honest answer: have them check the notice comes from you and, if unsure, phone you on the number they already had — not the one in the email. That same caution protects them from the people who genuinely will try to deceive them. ## 2. "Do I have to register?" No. They open the link and upload their files. No account, no password, nothing to install. It is the most reassuring point, and worth saying in the email before they ask. ## 3. "Will it cost me anything?" Never. Neither delivering nor signing. The cost sits with you, who are doing the asking. ## 4. "Who will see my documents?" Only you. Not other suppliers, not even those on the same case. If you work with two who compete, this is the first thing you need to be able to say. ## 5. "Does this hold up legally?" Yes, and with more evidence behind it than paper: when it was opened, how identity was checked and the exact moment of signing are all recorded. On a hand-signed sheet, nobody notes the time. > [!NOTE] > Link them the glossary article explaining the words in the notice. It is in six languages and settles the conversation without you having to have it. > [!WARNING] > If someone replies to the email instead of using the link, it is not distrust: they did not see there was something to click. Two lines from you unblocks it. **Can I warn them in advance?** Yes, and it lifts response a lot: a message from you saying "this is coming" prevents half the questions. **What if they refuse to use it?** It is nearly always unfamiliarity. One phone call achieves more than three emails. **Does it work if they only have a phone?** Yes. Most people open it on a phone. ## Ejemplos **A company sends its first batch and gets eight emails asking whether it is safe.** - Replies with the five answers - Includes them upfront in later sends and links the glossary → The questions disappear and delivery rises from the second send onward. **A small supplier asks whether they have to register for anything.** - Explains it is uploaded from the link, with no account or password → The supplier delivers the same day instead of waiting to phone and ask. **A supplier cannot tell which of the requested documents they already sent last year.** - Shows them exactly what is missing and what is already in → They send only what is missing and stop resending what you had. **Somebody asks who inside the company will see their data.** - Answers what is shared and with whom, and puts it in the notice → The doubt is settled once and does not return with every round. **A supplier says the link has expired.** - Resends the request from the same file → Nothing has to be rebuilt or re-explained. **The same five questions arrive with every send.** - Includes the answers in the notice itself and links the glossary → The second send generates half the emails of the first. --- --- id: KB-PS-008 url: https://app.codecontract.io/help/getting-started/can-i-manage-this-with-a-spreadsheet idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-004, KB-PS-009] citadoPor: [KB-PS-009, KB-CF-011, KB-CF-013, KB-PS-012, KB-PS-016] --- # Can I manage this with a spreadsheet? _When it is enough, when it stops being enough, and exactly how you notice._ **Responde a:** manage document control in a spreadsheet · alternative to excel for supplier documentation · shared folder or document management software · spreadsheet vs platform for supplier control · when does a spreadsheet stop working Almost everyone starts this way, and for a while it works. The useful question is not whether a spreadsheet works — it does — but when it stops working and how you notice. ## When it genuinely is enough **En corto** - Fewer than twenty third parties with documentation. - One person maintains it and that person is always there. - Nobody will ask you to prove when each item arrived. If that describes you, a spreadsheet and a shared folder is the right answer, and building anything else is work that returns nothing. It is honest to say so. ## The four signs it has been outgrown | The sign | What is actually happening | | --- | --- | | Someone asks "is this up to date?" | The sheet says what someone typed, not what exists | | An expired document is found by chance | Nothing warns; control depends on someone looking | | It takes half an hour to find something from two years ago | Only its author understands the structure | | You have to prove when a document arrived | A file's date can be changed by anyone | > [!IMPORTANT] > The fourth cannot be fixed with a spreadsheet, however well kept. A file's creation date can be changed by anyone in two clicks, so in a dispute it proves nothing. If your problem is being organised, the sheet works; if it is being able to prove, it does not. ## What does not change when you switch The work of asking still exists. What changes is who does it: chasing stops being yours and status stops depending on someone updating a cell. But if the process is badly designed, it will stay badly designed. > [!WARNING] > Migrating the whole sheet is the classic mistake. Bring what is current and leave the history where it is: what has not been consulted in a year will not be consulted. > [!NOTE] > A cheap test: take the document you were asked for last week and time how long it takes to find it and to say when it arrived. If it is more than two minutes, there is your answer. **Can I start with only part of it?** Yes, and it is recommended: one process, whichever repeats most. **Do I lose what I already have?** No. You upload what is current and the rest stays where it is. **Is it worth it if there are four of us?** It depends whether anyone asks you to prove dates. If not, probably not. ## Ejemplos **A company tracks 45 suppliers in a spreadsheet and finds three lapsed insurance policies at an inspection.** - Uploads only current documentation - Marks the expiry dates → The sheet stops being the control and becomes a list; expiries warn on their own. **Two people edit the same sheet and a row is lost.** - Each document gets its own file and history → There is no longer a good version that has to be guessed at. **The sheet says the policy is current and the PDF behind it is two years old.** - Stores the document with the figure and reads the date from it → The figure can no longer contradict the paper backing it. **Documentation is requested by email and the sheet updated by hand afterwards.** - The request and the status are the same thing → The step where updating gets forgotten disappears. **Whoever maintained the sheet leaves and nobody knows what a column meant.** - Statuses stop being one person's criteria → The information stays readable without that person. **An audit asks you to evidence fifteen suppliers' validity.** - Shares the files with their documents and dates → You hand over what backs the sheet rather than the sheet. --- --- id: KB-PS-009 url: https://app.codecontract.io/help/getting-started/what-it-costs-and-what-it-depends-on idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-008, KB-CD-005, KB-PS-019] citadoPor: [KB-PS-008, KB-PS-012] --- # What it costs and what it depends on _What you pay for, what you do not, and how to estimate before talking to anyone._ **Responde a:** how much does electronic signature cost · document control software price · cost of sending documents for signature · is there a free version · what would it cost for 50 suppliers It is the search people run right before deciding, and the one answered worst almost everywhere. What can be explained without talking to anyone is what it depends on, which is what lets you estimate it. ## The two pieces There is **a licence**, which grants access to the platform, and **credits**, which pay for what you do with it. They are different things: the licence does not include unlimited usage, and credits are no use without an active licence. ## What consumes a credit Practically any action the platform performs for you, at **one per action rather than per recipient**: | Action | Consumes | | --- | --- | | Sending for signature | 1 per send | | Sending a notice by email, SMS or WhatsApp | 1 per request, even if it goes to several | | Creating or duplicating a process | 1 | | Uploading a document | 1 | | Reading a document with AI | 1 | | Certifying or sealing evidence | 1 | | Generating a report | 1 (downloading it, no) | | Viewing and filtering what is stored | Does not consume | > [!NOTE] > Cost following the action rather than the recipient is what most changes the sum: a batch to three hundred people consumes the same as one. ## How to estimate it yourselves Count **how many actions a month**: signature sends, notices, processes created, documents uploaded and read. That number times the unit price is your consumption; the licence sits alongside. A common error is estimating by number of suppliers — that is not what you pay for. > [!IMPORTANT] > A bulk send counts as **one** action, not one per recipient. It is the biggest difference from what people assume when estimating, and it is in your favour: the annual amendment to three hundred employees is not three hundred send credits. > [!WARNING] > Be careful comparing price alone. What to compare against is what it costs you now: chasing time, paper, courier, and — the one nobody adds up — what an unprovable claim costs. > [!NOTE] > The cheap way to find out is to try it on a real process of your own. One genuine case gives a better number than any abstract estimate. **Is there a free version to try?** You can try it on a real case with nothing to install; the exact scope is shown when you sign up. **Is it charged per user?** The licence and its scope are agreed separately; variable consumption follows the table above. **Do credits expire?** Not with time; if the licence lapses they cannot be spent. ## Ejemplos **A company wants to know the cost before talking to sales.** - Counts 40 signatures a month and 150 documents read - Adds the annual 300-send amendment separately → Arrives at the conversation with their own number instead of a question. **A company fears paying for users who barely log in.** - Counts what actions actually happen per month → The estimate rests on real usage rather than headcount. **It is unclear whether requesting documents from a hundred suppliers drives consumption up.** - Checks which activities consume and which do not → The number of recipients stops being the unknown. **One month has a big campaign and the rest are quiet.** - Estimates the peak month separately from a normal one → You size for the year rather than for the worst month. **You want to compare against what doing it by hand costs today.** - Counts the hours spent today chasing and keying → The comparison uses both figures rather than one. **Management wants a number before authorising a trial.** - Brings the per-activity calculation and the growth assumption → The authorisation is discussed on an explicable number. --- --- id: KB-PS-010 url: https://app.codecontract.io/help/getting-started/the-five-first-month-mistakes idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-TL-014, KB-PS-020] citadoPor: [KB-PS-011] --- # The five first-month mistakes _All avoidable, and all five happen for the same reason._ **Responde a:** mistakes when starting with the platform · what not to do in the first month · why is my process not working · tips for starting well All five happen for the same reason: wanting everything set up before using it. It is a reasonable instinct and it is exactly what leads to nobody using it two months later. ## 1. Building twelve processes before using one It takes two weeks, gets abandoned at the first difficulty, and teaches you nothing about how your third parties respond. One complete real case teaches more than twelve designed in the abstract. ## 2. Migrating the whole archive Twelve years of documents nobody has consulted in years. It occupies the start, clutters searches and returns nothing. Bring what is current and what expires; the rest goes up the day someone looks for it. ## 3. Marking everything mandatory It ends with cases blocked by what never mattered, and someone bypassing the process to get work done. Mandatory means what stops things, not what would be nice to have. ## 4. Inviting the whole team on day one They arrive at an empty account, cannot see the point and do not come back. Convincing them afterwards costs double, because the impression is already formed. ## 5. Writing titles for yourselves "Doc 3" or "SS cert." mean nothing to whoever receives them. It is the cheapest mistake to fix and the one that recovers the most delivery. > [!IMPORTANT] > If you could avoid only one, avoid the first. The other four are corrected in an afternoon once spotted; the first consumes the initial momentum, and that does not come back. ## What does work in month one **En corto** - One real case, end to end, even if it is slower that time. - Saving it as a template once it works. - And only then inviting whoever will use it. > [!NOTE] > The sign you are on track is not having a lot built: it is a colleague asking whether one of their cases could go through it. **What if I already made one?** The last four are corrected in an afternoon. The first is corrected by starting again with a real case. **How long until the effect shows?** With one process, two weeks. With twelve unused, never. **Is it worth starting in peak season?** Better not: build in the quiet season what you will need in the busy one. ## Ejemplos **A company builds eleven processes in two weeks and two months later nobody uses them.** - Starts again with a real case that was on their desk - Saves it as a template once it works → Three weeks later three people are using it, with nothing else built. **Thirty people are invited before any process exists to use.** - Whoever will use it that week comes in first → Nobody receives access to an empty tool. **The paper circuit is copied as-is, unnecessary steps included.** - Reviews which steps existed only because paper travelled → The new process is shorter than the one it replaces. **It is decided to wait until everything is perfect before requesting anything.** - Launches a real request with what exists → Adjustments come from use rather than from a meeting. **You start with the company's most complicated process.** - Picks one that repeats often and is simple → The first result arrives in days, not months. **Nobody sets a date to decide whether to continue.** - Sets the thirty-day date from the start → The decision is taken on data rather than by inertia. --- --- id: KB-PS-011 url: https://app.codecontract.io/help/getting-started/the-first-hour idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-PS-010] citadoPor: [KB-MA-014, KB-PS-018, KB-PS-022] --- # The first hour _What to do right after logging in to find out whether this helps, without setting anything up._ **Responde a:** i have just logged in for the first time · what do i do first on the platform · trying the platform without setting anything up · first hour of use The normal reaction on first logging in is to start configuring: add the team, import contacts, build the structure. That is exactly what not to do yet, because you would be deciding how to organise something you do not yet know the workings of. ## What is worth doing, in one hour 1. **Take a real case of yours, a small one** — A specific supplier, a specific document. Nothing invented: invented cases teach nothing. 2. **Upload a genuine document** — One of the ugly ones: scanned, skewed, stamped. That is the one that shows you how it behaves. 3. **Send something for signature to yourselves** — So you see what the recipient sees, which is half the decision. 4. **And search for something you uploaded** — By a value inside it, not by the filename. > [!IMPORTANT] > That fourth step is the one most people skip and the best predictor of whether this will help you. If you can find a document by what it says inside, you have solved half your problem even with nothing else configured. ## What can wait | Can wait | Why | | --- | --- | | Inviting the team | Better once you know what you will ask them to do | | Importing all contacts | Three are enough to try it | | Building the final structure | It will change once you use it for two weeks | | Integrations | It nearly always turns out they were not needed at first | > [!WARNING] > The classic day-one mistake is loading the whole historical archive. It eats an afternoon, teaches nothing new, and fills the house before you know where anything goes. Old material comes later, and often only part of it was needed. ## What to look at when the hour is up **En corto** - Did the ugly document read reasonably well? - Is what the other party receives understandable without explanation? - Did you find what you uploaded, searching the way you really would? If all three are yes, the decision is made and you can move on to setting up. If any is no, that is exactly the conversation to have before going further. > [!NOTE] > This hour's actions consume like any other: uploading, sending for signature and reading a document cost the same in a trial as in production. It is little, but worth knowing before repeating the test thirty times. **Do I need to install anything?** No. It runs in the browser and on a phone. **Can I delete the trial material afterwards?** Yes, though it usually stays: it is real documentation of yours. **What if I am not sure which module I need?** Try the case that hurts most today; the module follows by itself. ## Ejemplos **A company spends day one importing five years of archive.** - Stops and tries a real case: one supplier, one ugly scan, one signature to themselves - Searches the document by tax ID → Decides on evidence within an hour, and brings the archive once it knows where things go. **You want to know whether automatic reading works on the company's real documents.** - Uploads the worst scan to hand - Looks at which fields come out and which do not → The decision uses your own material rather than a demo example. **Nobody knows whether a supplier will manage to upload something unaided.** - Sends themselves a request and completes it from a phone → You see the other side's experience before sending it to anyone. **There is doubt about whether a signature will be enough.** - Signs a test document and looks at the trail it leaves → The doubt is settled by looking at the evidence, not the description. **You want to check whether a document can be found again afterwards.** - Searches by something in the content rather than the file name → It becomes clear whether search will help day to day. **The first hour goes on browsing menus.** - Walks one complete case from start to finish → You come out with an opinion rather than a guided tour. --- --- id: KB-PS-012 url: https://app.codecontract.io/help/getting-started/what-to-ask-before-signing-up idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-008, KB-PS-009] citadoPor: [KB-PS-016] --- # What to ask before signing up _Eight questions worth asking any platform, this one included._ **Responde a:** what to ask a software vendor · criteria for choosing a document platform · how to compare document management tools · questions before signing a saas contract Almost every demo shows the same thing: what the tool does well. The questions that separate a good decision from regret eight months later are different, and none is about features. ## The eight questions 1. **How do I get everything out if I leave?** — In what format, how long it takes, and whether it includes the original documents, not just a listing. 2. **Where is my data and who can see it?** — Country, subprocessors, and which people at the vendor have technical access. 3. **What happens if I stop paying?** — Whether it locks, whether it is deleted, and how long I have to retrieve. 4. **What breaks when they change the product?** — With how much notice, and whether what you built still works. 5. **Who answers when something fails on a Friday?** — In what language and with what response commitment. 6. **What does it really cost in year two?** — With foreseeable growth, not the demo scenario. 7. **What do I need from my IT team?** — If the answer is "nothing" and a project turns out to be needed, now you know. 8. **Can I try it on a case of mine before deciding?** — With your real documents, not the sample ones. > [!IMPORTANT] > The first and third are most often skipped and cost the most. A platform you cannot leave with your documentation is not a tool: it is a dependency. ## What to check as well as ask | Aspect | How to actually check it | | --- | --- | | Ease of use | Have someone on your team use it without training | | Speed | With one of your large documents, not a sample | | Support | By sending a real question before signing | | Security | By asking which certifications they hold and from when | > [!WARNING] > Be wary of answers beginning "that's on the roadmap". Buy on what it does today: what is coming may come, and your problem is this quarter's. ## And about this platform specifically **En corto** - You can export your complete documentation whenever you want. - What is signed and sealed can be verified even after you stop being customers. - It can be tried on a real case of yours before deciding anything. - And what it costs depends on usage, with a breakdown to check it. > [!NOTE] > If any of the eight gets an evasive answer, that is itself an answer. It does not need to be perfect: it needs to be clear. **What if I already signed without asking?** Ask now: the first and third matter just as much. **How long should a trial last?** As long as it takes to run one real case end to end. **Are references worth asking for?** From someone your size and sector, yes. From a flagship case, little. ## Ejemplos **A company compares three tools by their feature lists.** - Asks all three the eight questions - Trials a real case with the two that answer clearly → Finds one cannot export original documents and rules it out before signing. **You wonder whether the data can be recovered the day you want to change.** - Asks for a test export before signing → The exit is verified rather than assumed. **Nobody clarifies what happens to the documents if you stop paying.** - Asks about the access period and the delivery format → The answer is in writing before you depend on it. **Comparison is by list price without knowing what each action consumes.** - Asks which activities consume and which do not → The comparison uses expected usage rather than a price tag. **A tool looks complete but nobody has tried the supplier side.** - Asks for a trial with a real external recipient → You see the half of the product that never appears in the demo. **You sign without knowing who answers when something breaks.** - Asks about the support channel and the committed response time → The first problem is not also the first surprise. --- --- id: KB-PS-013 url: https://app.codecontract.io/help/getting-started/the-first-thirty-days idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-PS-005] citadoPor: [KB-PS-016, KB-PS-017, KB-PS-019, KB-PS-020] --- # The first thirty days _What to expect each week, and which week the doubt usually appears._ **Responde a:** first month using the platform · simple rollout plan · what to do in the first weeks · how long before it shows A month is enough to know whether this helps you, provided it is done in a specific order. This is the one that works, with a warning about where the dip is. ## Week by week | Week | What to do | What you notice | | --- | --- | --- | | 1 | One real case end to end, just you | Whether the system fits your case | | 2 | A full process with real third parties | The first reply from someone outside | | 3 | Bring the team into that same process | Where people get stuck, which is never where you expected | | 4 | Automate chasing and review | The first real time saving | > [!IMPORTANT] > Week 3 is the dip. It is when the team asks why something that "already worked" is changing, when the exceptions nobody mentioned appear, and when it is decided whether this stays or is abandoned. It is not a sign of failure: it is the week everyone has. ## How to get through week 3 1. **Listen to the specific complaint, not the general one** — "It's slower" almost always means "I can't find X" or "I don't know what's mine". 2. **Fix whatever you can the same day** — Two quick fixes beat a meeting explaining the benefits. 3. **And add nothing new that week** — That is the temptation: adding another process to prove the point. It makes everything worse. > [!WARNING] > The commonest first-month mistake is starting by importing the historical archive. It eats week 1, teaches nothing about whether the system suits you, and fills everything before you know where things go. ## What to look at on day thirty **En corto** - How often someone had to ask where something stood. - How long the first full process took versus how you did it before. - And whether anyone on the team uses it without being reminded. The third predicts the rest. If at thirty days at least one person logs in of their own accord because it is easier than the old way, the change already stands without you. > [!NOTE] > All of this consumes: every upload, send and read counts in the trial month too. It is little, but worth knowing before repeating the same case twenty times to demo it to people. **What if nobody outside replies in week 2?** Check the send status before concluding anything: it is usually the recipient, not the system. **How many people should join in month one?** Those touching that process. Bringing in the whole company in month one is the fastest way to fail. **When do we import the old material?** From month two, and only what gets consulted or expires. ## Ejemplos **A company starts by importing five years of archive and by week 3 the team is complaining.** - Stops importing and fixes the two specific complaints - Returns to the single process until day thirty → By month end two people use it unprompted and the archive is brought in later, and only partly. **The first week goes on configuring and nothing is requested.** - Launches a real request on day one → Week one ends with a reply from outside rather than a screen set up. **In week two a case appears the process did not contemplate.** - Adjusts the process for that case and saves it again → The template improves through reality rather than being born perfect. **In week three somebody says email used to be faster.** - Listens to the specific complaint and fixes that step → The objection becomes a change rather than an argument. **At month end nobody knows whether it helped.** - Compares how long closing a file used to take → The decision to continue is taken with a figure. **There is a wish to extend to another process before finishing the first.** - Finishes the first one all the way to closing → The second starts on something proven rather than a hunch. --- --- id: KB-PS-014 url: https://app.codecontract.io/help/getting-started/which-process-to-start-with idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-004, KB-CF-013] citadoPor: [KB-PS-018, KB-PS-020] --- # Which process to start with? _The highest-yield one is not the biggest: it is the one that makes you chase someone outside._ **Responde a:** where do i start rolling this out · which process to digitise first · choosing the first use case · start with the easiest or the most useful The choice of first process decides whether the project moves by itself or has to be pushed every week. And almost everyone chooses badly for the same reason: they start with something internal, which is easy to change, when the return lies in what goes outward. ## The three usual candidates | Candidate | Return | Difficulty | Verdict | | --- | --- | --- | --- | | Supplier or contractor documentation | High | Medium | The best first, nearly always | | Staff signatures | High | Low | A good first if there is turnover | | The historical archive | Low at first | High | Never first | > [!IMPORTANT] > The first wins because it combines three things: someone outside is involved, documents expire, and it repeats. Those three together are exactly where a tool like this returns time from week one. ## How to scope it to fit a month 1. **One supplier type, not all of them** — The hauliers, or one site's subcontractors. Ten or fifteen, not two hundred. 2. **The document list you already request** — Do not take the chance to redesign what is asked for: that is another project. 3. **With the people who already do it** — The whole company does not need to join to test one process. 4. **And a date to decide** — Thirty days. Without a date the trial stretches until nobody remembers what was being tested. > [!WARNING] > The second sinks the most projects. Setting up the process brings the temptation to review which documents are requested, who approves and against what criteria — and suddenly the project depends on three decisions that are not yours. ## Signs you chose well **En corto** - Within two weeks someone outside has supplied without being called. - Someone on the team asks whether another case can be added. - And "how's X going?" is answered by looking, not asking. If none of the three has happened after a month, you probably chose a process that was too internal or too infrequent. That is not failure: it is information for choosing the next one. > [!NOTE] > What does not help is starting two processes at once "to go faster". If something fails you will not know which caused it, and the conversation with the team becomes vague. **What if our most painful case is internal?** Do it anyway, knowing the return will be smaller and slower. **How many people should take part?** Those already doing that work. Adding spectators does not help. **Can we switch process midway?** Yes, and sometimes it is right. Note why — that is the instructive part. ## Ejemplos **A company wants to start by uploading its whole historical archive.** - Starts with documentation from fifteen hauliers - Sets a decision date at thirty days → Within two weeks the hauliers supply unprompted and the archive is postponed to month two. **The chosen process depends only on people inside.** - Picks one that means waiting on somebody outside → The saving shows from week one, because that is where the lost time is. **You start with something that happens twice a year.** - Picks what repeats every week → The template pays for itself in the first month. **The chosen process is run by one person and nobody else sees it.** - Picks one two or three people touch → Somebody beyond whoever set it up notices the result. **You pick the most important process, which is also the most delicate.** - Starts with one where a mediocre result breaks nothing → You learn without risking the critical process. **Nobody knows which process consumes most time today.** - Asks where the week goes before choosing → The choice rests on real time rather than an impression. --- --- id: KB-PS-015 url: https://app.codecontract.io/help/getting-started/who-should-own-this-internally idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: administrador nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-005, KB-CR-011] citadoPor: [KB-PS-019] --- # Who should own this internally _The person who makes it work is not the most technical: it is whoever suffers the problem today._ **Responde a:** who should own the platform internally · internal rollout owner · should it be IT or the department · who administers the tool It is the least considered decision and the one that most determines whether this sticks or gets abandoned. It usually gets settled by elimination — "let IT handle it", "let whoever has time handle it" — and both outcomes fail for the same reason: whoever owns it is not whoever has the problem. ## The three usual profiles | Profile | What they bring | Why it fails if they are the only one | | --- | --- | --- | | Whoever suffers the problem | Knows what has to happen and notices when it works | May lack backing for decisions that affect everyone | | IT | Solves access, domain, integrations | Does not know what documentation you require or why, and should not decide it | | Management | Unblocks decisions and budget | Alone, nobody uses it day to day | > [!IMPORTANT] > The combination that works is the first with occasional support from the other two: **the owner is whoever chases documents today**, IT steps in for domain or access work, and management appears to decide what crosses departments. Making IT the owner is the commonest and costliest mistake: they end up administering a tool whose purpose they do not live. ## What the owner must be able to do **En corto** - Decide what is requested and from whom, without asking permission each time. - Change a template or an alert the same day it turns out not to fit. - And say no to adding things before the basics work. The third is most underestimated. As soon as something starts working, requests arrive from other departments, and an owner who cannot say "that comes later" ends up with five half-built processes instead of one finished. ## The mistake of sharing it out > [!WARNING] > Two people "owning it together" without one being responsible is the most reliable formula for nobody owning it: each assumes the other reviews what is pending, and neither decides when a decision is needed. One is responsible and the others help — and that is said out loud on day one, not inferred. ## How much time it really takes 1. **The first two weeks: a few hours** — Building the process, testing it, correcting it. That is when it is most needed. 2. **The first quarter: a while each week** — Checking what is stuck, tuning alerts, answering the team's questions. 3. **Afterwards: half an hour a month** — The tidy-up and the access review. If it needs much more, something is built more elaborately than necessary. > [!NOTE] > If that person leaves or changes role, the handover is explicit: who picks up the owner's role, by name. An owner who disappears with no successor is the commonest reason a rollout that was going well fades within three months. **What if we are too few to name anyone?** Then the owner is whoever chases documents most, even if that is the manager. **Can an external adviser own it?** They can operate it, but the decision owner has to be inside. **Does it have to be someone technical?** No. The technical part is small and occasional. ## Ejemplos **A company hands the rollout to IT and two months later nobody uses it.** - Names the person who chased documentation as owner - Keeps IT for domain and access work → The process adapts to what actually happens and usage rises with no extra training. **The named owner has no time allocated for it.** - Reserves fixed hours each week during the rollout → The project stops competing with the day's urgencies. **Someone is named who cannot decide how the work is done.** - Picks someone who can change the procedure, not only run it → Adjustments are applied without asking permission each time. **The owner leaves and nobody knows how it was set up.** - Documents decisions inside the process itself - Keeps a second person with access from the start → One person leaving does not freeze usage. **IT builds the process and whoever uses it does not recognise their work in it.** - Has it designed by whoever chases the documentation today → The process resembles the real work from the first version. **Nobody knows who to ask when something does not fit.** - Announces who the owner is and how to reach them → Questions reach somebody instead of becoming excuses. --- --- id: KB-PS-016 url: https://app.codecontract.io/help/getting-started/what-this-will-not-solve idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-008, KB-PS-013, KB-PS-012] citadoPor: [KB-PS-019] --- # What this will not solve _Five problems people expect to vanish on rollout, and that do not vanish._ **Responde a:** what the platform does not do · limits of a document system · will this fix my chaos · realistic expectations for a rollout A tool is judged by the gap between what was expected and what it does. These are the five expectations we see most often and that are worth discarding on day one, because discovering them in month two takes the whole project down. ## The five | People expect it to… | The reality | | --- | --- | | Tidy the archive you already have | It tidies what comes in from today; old material is brought over and tidied separately | | Make people reply | It makes chasing automatic, not a supplier willing | | Decide what is acceptable | It checks presence and expiry; approving is your decision | | Replace a process that does not exist | If nobody knows which documents to require, the tool does not invent them | | Correct whoever will not use it | It reduces work for those who use it; it does not reach those who never log in | > [!IMPORTANT] > The fourth sinks the most projects and is the least admitted out loud. If in your company each person asks for different documentation by their own judgement, rolling this out unifies nothing: it reproduces the disorder faster and with a better appearance. That conversation — what is required and why — has to happen anyway, and it is cheaper first. ## What does change, so the comparison is fair **En corto** - Chasing stops being a job: it happens by itself, with a record. - It stops depending on who was around: what was done stays where anyone can see it. - And expiry surprises stop, which is what shows most in the first quarter. > [!WARNING] > The AI misunderstanding deserves its own point: **it reads, extracts and summarises, but it does not decide and does not answer for what it asserts**. An extracted value is a value you must be able to check, and a summary is a starting point, not a conclusion. Whoever signs is still a person, and that is not a temporary limitation: it is how it should be. ## What you decide and no tool should 1. **What documentation you require and from whom** — A business decision, not a configuration one. 2. **What happens when someone fails** — Block, escalate or accept the risk. Written beforehand, not in the heat. 3. **And who answers for each thing** — A file with no owner does not move, however automated it is. > [!NOTE] > If after reading this you still see the fit, that is a good sign: rollouts that go well start with adjusted expectations rather than enthusiasm. And if one of the five was exactly what you were hoping for, better to know today. **So what is it for?** So that what you already do stops depending on memory and on chasing people. **What if our problem is not knowing what to ask for?** Start there; the article on what your suppliers will ask you helps to begin. **Is it worth it with teams that resist?** Yes, if you start with the process that annoys them most, not the one that interests you most. ## Ejemplos **A company rolls this out expecting its ten-year archive to be tidied.** - Adjusts the expectation: new material is tidy, old comes over in stages - Starts with supplier documentation → At three months it judges the result by the chasing it stopped doing, not by the old archive. **You expect suppliers to start answering unprompted.** - Automates the reminder while keeping the relationship → You chase less; you do not stop chasing. **You expect automatic reading to be right every time.** - Reviews whatever the AI flags as uncertain → The work shifts from keying to checking, which is far less. **You expect arguments about who was right to disappear.** - Keeps a dated trail of every step → The argument still happens, but it closes by looking rather than remembering. **You expect it to decide which documents to request.** - Writes the list once and reuses it → The decision stays yours, but it is taken only once. **You expect it to sort the old archive on its own.** - Sorts what is new from day one and brings the old in stages → The mess stops growing, even if the history stays where it was. --- --- id: KB-PS-017 url: https://app.codecontract.io/help/getting-started/from-trial-to-working-for-real idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-013, KB-PS-005] citadoPor: [KB-PS-020] --- # From trial to working for real _The day it stops being an experiment and becomes where the work lives: what to tidy first._ **Responde a:** moving from trial to real use · cleaning up test data · starting to use it properly · what to do when the pilot ends Almost every rollout has an odd moment: the trial went well, the decision is to continue, and nobody declares the change. The result is a half-and-half space where real files live alongside tests, and where nobody knows whether what they are looking at is real. ## What to tidy before saying "this is now the real thing" 1. **Test files: close or delete, but decide** — An open test file pollutes every count and shows up in any report. 2. **Invented contacts** — If you tested by sending to yourselves under fake names, remove them: they end up receiving real reminders. 3. **Templates built on the fly** — Review texts and lists: the ones made for testing often say things you would not say to a client. 4. **And who comes in from now on** — Two people ran the trial; real use is done by whoever touches that process. > [!IMPORTANT] > The second point causes the frights. A test contact with a real address — yours, a colleague's, a client's used "because it was handy" — is still in the system and receives whatever goes out from there. Automatic chasing does not distinguish what was a test from what was not. ## What to declare out loud | What is said | Why it matters | | --- | --- | | From when this is the real place | Without a date, half the team will carry on as before | | Which processes are in now and which are not yet | It stops someone putting in the wrong thing and concluding it does not work | | Who to ask when something does not add up | It is what prevents silent abandonment | | And what happens to the old system | Read-only, reference only, or nothing: but stated | > [!WARNING] > The commonest mistake here is wanting to bring everything in at once because "it's already been tested". The trial validated one process with two people; adding five processes and fifteen people in the same week turns any small problem into a reason to go back. What works is one process at a time, two or three weeks apart. ## Signs the step went well **En corto** - Someone who did not take part in the trial logs in unprompted and does their work. - A request appears for a case you had not anticipated — a sign it is genuinely in use. - And nobody asks any more whether something is "in the system or in the folder". > [!NOTE] > Any test files you decide to keep, mark them as such in their name. A year from now, someone will find them searching for something else and needs to know within two seconds that it was not real. **Should test documents be deleted?** If they were genuinely yours, no need: close the file and move on. If they were invented, better out. **What if the trial was run by someone no longer on the project?** Check what was left in their name before continuing: alerts and tasks included. **Can we go back if it goes badly?** Yes, and that is why entering process by process beats all at once. ## Ejemplos **A company finishes the pilot and carries on without closing the test files.** - Closes the tests, removes invented contacts and announces from when this is the real place → Reports stop mixing and nobody asks again whether what they see is real. **Test contacts keep receiving real notices.** - Deletes the made-up contacts before opening it to the team → Nobody outside receives an email from a trial. **Nobody knows from what date the contents are real.** - Announces the day from which this is the live place → Doubts about whether a file is real disappear. **The trial process and the final one coexist under similar names.** - Archives the trial one and leaves a single active version → Nobody launches a request from the wrong template. **Permissions are still the pilot's, with everyone seeing everything.** - Reviews who should see what before the others come in → Access is decided before there is real information inside. **Reports mix trial data with the first real records.** - Closes the trial files before the switch → The first report shown is usable. --- --- id: KB-PS-018 url: https://app.codecontract.io/help/getting-started/starting-with-a-deadline-on-top idioma: en categoria: primeros-pasos subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-014, KB-PS-011, KB-PS-023] citadoPor: [KB-SC-001] --- # Starting with a deadline on top _Nobody starts calmly: you start because there is an audit, a client or a site in three weeks._ **Responde a:** I have an audit in three weeks where do I start · rolling out fast before a deadline · a client is asking for documentation now · starting with no time to prepare The orderly rollout — mapping processes, training the team, migrating history — is the one told in presentations. The real one nearly always starts with a date: an announced audit, a new client demanding documentation, a site about to open. And with a deadline on top, the right order changes. ## What changes when there is a deadline | With time | With a deadline on top | | --- | --- | | Start with the most repeated process | Start with what they will ask for on the day | | Migrate the history | Migrate only what falls within that date's scope | | Train the whole team | Train whoever will touch it these weeks | | Tune it until it fits | Accept what works and tune it afterwards | > [!IMPORTANT] > The mistake that ruins most rushed starts: **trying to bring everything in «while we are at it»**. With three weeks, loading five years of history or onboarding thirty suppliers outside that audit's scope does not get you closer to the date — it eats it. Anything that will not be looked at on the day is done afterwards, and done better, because by then you will know how you work inside. ## The three weeks, in order 1. **Write down exactly what they will ask for** — With the auditor's or client's list in front of you, if you can. 2. **Load only that, and check it can be found** — Finding it in twenty seconds is the test, not having uploaded it. 3. **Request whatever is missing, one message per item** — It is the slowest part: it depends on third parties, not on you. 4. **And rehearse the handover once** — Show a colleague as if they were the auditor. That is where the gaps appear. > [!WARNING] > What almost nobody sizes correctly: **anything depending on a third party takes weeks, not days**. A certificate an official body has to issue, an insurance policy the broker has to update, a signature from someone on holiday. Those requests go out on day one, before anything is tidy — you can speed up your internal order, you cannot speed up an outside answer. ## After the date, not before **En corto** - Migrate the history that was not needed that day. - Extend to the other processes, now with your own judgement. - And review what was done by hand in a rush, to automate it before the next one. > [!NOTE] > A partial first rollout is not a debt: it is the only kind that finishes. A complete rollout that misses the date is worth nothing; a partial one that makes it carries the next stage. **What if we do not get to everything?** Hand over what there is and say what is missing and by when. Hiding it is worse. **Is it worth starting this tight?** Yes, if you narrow the scope. A real date organises more than no date at all. **Do we bring the whole team in from day one?** No: only whoever will touch it these weeks. The rest, later. ## Ejemplos **A company has a client audit in three weeks and nothing in order.** - Asks the client for the list, sends third-party requests on day one and loads only that scope → It reaches the audit with what is asked for findable, and tidies the rest calmly afterwards. **Three weeks remain and the work starts by building the full structure.** - Loads only what the deadline requires and leaves the rest → You reach the date with what is asked for, not half an archive. **Whatever depends on third parties is requested in the final week.** - Launches on day one everything somebody outside must answer → Waiting time runs in parallel with the internal work. **Nobody knows exactly what is missing five days out.** - Checks status per file instead of asking by email → The last days go on closing specific gaps. **Halfway through, a document nobody requested turns out to be missing.** - Checks the list with whoever will audit before starting → The scope is set with whoever will review it. **Once the date passes, everything stays as it was left.** - Reserves a week afterwards to tidy what was done in a hurry → The rush leaves a usable system rather than a patch. --- --- id: KB-PS-019 url: https://app.codecontract.io/help/getting-started/how-much-time-this-really-takes idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-013, KB-PS-015, KB-PS-016] citadoPor: [KB-PS-009] --- # How much time this really takes _The question nobody asks in the demo and the one that decides whether this sticks. The work does not vanish: it moves._ **Responde a:** how long does this take to implement · who is going to spend hours on it · we have nobody for this · how much work is it to maintain Demos show how quickly everything gets done, and that is true. What they do not show is that at some point someone has to sit down and decide what is requested, from whom and how often — and that stretch of time exists, however you dress it up. ## Where the time goes, by phase | Phase | What it usually costs | Who does it | | --- | --- | --- | | Deciding what is asked and from whom | A few hours, once | Whoever chases those documents today | | Building the first process | Less than you would think | The same person | | Loading what you already have | Depends how much you bring | It can be shared out | | The first month of running in | A short stretch each day | Whoever owns it | | From then on | Less than before you started | The team, without noticing | > [!IMPORTANT] > The row that decides the outcome is the first, and it is the one everyone tries to skip: **thinking through what exactly is requested is the work, building it is the formality**. If those hours are not spent at the start, they are paid in months of corrections, badly framed requests and outsiders asking what you actually want. It is not implementation time: it is time spent ordering what you were already doing from memory. ## What stops happening **En corto** - Chasing by phone what someone should have sent a fortnight ago. - Hunting for a document that lived in someone else's inbox. - Rebuilding a whole folder before every audit. - And explaining for the umpteenth time which papers are needed. > [!WARNING] > Something worth saying that the numbers do not show: **the saving does not appear where the work was**. Whoever was chasing stops chasing, but whoever builds the processes spends time up front, and they are not always the same person. If the one who gains time and the one who invests it differ, say so out loud at the start — otherwise the person carrying the initial load ends up feeling this only added work for them. ## A realistic split for a small company 1. **One unhurried afternoon for the first process** — Better a whole afternoon than six twenty-minute slots. 2. **Fifteen minutes a day for the first two weeks** — Look at what arrives and fix what does not fit. 3. **Half an hour a month tidying up** — What is stalled, what has no owner, what is about to expire. 4. **And a longer review once a year** — Permissions, templates and whatever is no longer used. > [!NOTE] > If nobody can spare that first afternoon, it is better to start with a smaller process than to start five half-built. What sinks a rollout is not going slowly: it is leaving three things half-set-up and nobody knowing which is live. **Do we need to hire someone?** In a small company, no. Someone needs to have the time. **What if nobody has time right now?** Start with what is already costing you hours: it pays for itself. **How long before it shows?** The first weeks cost; the change shows on the second cycle. ## Ejemplos **A company spreads the start across odd moments and three weeks in nobody knows what is set up.** - Devotes a whole afternoon to one process and leaves it running → The second process takes an hour, because the hard decisions were already made. **Effort is estimated from training rather than from designing the process.** - Counts the time spent deciding what is requested and from whom → The estimate includes the part that actually costs. **Nobody accounts for the time spent waiting on suppliers.** - Launches what depends on outsiders early → The wait is not added at the end of the schedule. **The rollout happens in odd moments between meetings.** - Blocks a whole afternoon for the first process → Decisions are taken once instead of picked up five times. **Maintenance is expected to be zero once it is set up.** - Reserves time monthly to review templates and expiries → The system is still true six months later. **Time spent is compared against zero rather than against the previous way.** - Measures how long closing a file used to take → The balance is struck against a real cost already being paid. --- --- id: KB-PS-020 url: https://app.codecontract.io/help/getting-started/the-first-supplier-you-ask idioma: en categoria: primeros-pasos subcategoria: configuracion-inicial audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-014, KB-PS-013, KB-PS-017] citadoPor: [KB-PS-010] --- # The first supplier you ask _The first request to an outsider teaches more about your process than any internal test._ **Responde a:** which supplier should I ask first · how do I tell a supplier we are changing · first request to a third party · pilot with a real supplier You can test all you like among colleagues: someone inside understands what you meant even when it is not written down. The process only starts existing for real when it reaches someone who does not know you, owes you nothing and has their own Monday. ## Who to pick as the first | Profile | Good first choice? | Why | | --- | --- | --- | | The one who treats you best | Yes | They will tell you what is unclear, without taking offence | | The one with most documents outstanding | No | You mix launching the process with an old dispute | | The biggest one | No | They have their own portals and their own rules | | A small one working from a phone | Yes, as the second | It is the acid test of your format | > [!IMPORTANT] > What to watch in that first request is not whether the document arrives: **it is how many questions they ask before sending it**. Every «what is this?», «are you asking or is your colleague?» or «will the one I sent last year do?» is a hole in your message, not carelessness on their part. The other forty will have the same doubts, except most will not ask: they simply will not reply. Each doubt fixed now is saved forty times over. ## How to prepare that first send 1. **Warn them on the usual channel before sending** — One line: «something is coming and it is from us». 2. **Ask for little: one or two things** — Launching with eight documents tests their patience, not the process. 3. **Say what happens once they send it** — Knowing someone reviews and confirms changes their willingness. 4. **And ask them afterwards how it went** — Two minutes of conversation beat staring at a dashboard. > [!WARNING] > The commonest launch mistake is not in the message: **it is not telling anyone inside that this supplier will now reply here**. They send the document, it arrives through the new system, and whoever handles that supplier keeps watching their own inbox — so the very first person to try the process waits a week and concludes it does not work. Before the first request, someone has to be watching the other side. ## What the replies you get actually mean **En corto** - Fast and correct: do not read too much into it, they are your friendliest. - Replies but sends the wrong thing: the problem is how you asked, not them. - No reply: check it reached them before drawing conclusions. - Asks whether it is compulsory: your message is missing the «why». > [!NOTE] > It is worth writing two lines about how this first one went, because by the fortieth nobody will remember what changed after that conversation — and those changes are usually the best ones the process gets. **Should I call or is email enough?** For the first one, a short call. After that it is unnecessary. **What if the first one goes badly?** That is exactly what it is for. Discovering it at forty would be worse. **How long before chasing?** As long as that supplier normally takes, not as long as you would like. ## Ejemplos **A company launches its process with the supplier that owes the most documents.** - Starts with a friendly one, asks for two documents and calls beforehand → The doubts come out in a conversation and get fixed before the other forty see it. **The most difficult supplier is chosen for the first trial.** - Starts with one you get on well with → The process's flaws surface in a friendly conversation. **Nine documents are requested at once the first time.** - Requests two and adds the rest in the next round → The first attempt completes and builds confidence on both sides. **The supplier does not understand why something is being requested.** - Explains in the notice why each document is needed → They reply without a preceding phone call. **No warning is given and the email looks suspicious.** - Phones before sending the first notice → The link gets opened rather than binned. **What was learned with the first one is not applied to the rest.** - Saves the corrected process as a template → The next forty receive the good version. --- --- id: KB-PS-021 url: https://app.codecontract.io/help/getting-started/do-i-have-to-create-an-account idioma: en categoria: primeros-pasos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-TL-003, KB-TL-021, KB-PS-022] citadoPor: [KB-PS-023] --- # Do I have to create an account? _To answer a request or sign, no. An account is only needed if you are the one doing the asking._ **Responde a:** do i need to register to upload a document · do i need an account to sign · do i need a username to reply · can i respond without signing up **No, if all you are doing is responding.** Uploading the documents you were asked for, or signing something, happens from the link you received — no username, no password, nothing to install. ## When an account is needed and when it is not | What you are doing | Account? | | --- | --- | | Uploading documents you were asked for | No | | Signing a document sent to you | No | | Viewing evidence or verifying a document | No | | **Asking others for documents yourself** | **Yes** | > [!IMPORTANT] > **If a screen asks you to create an account in order to answer a request, something is off: stop and check where that link came from.** The normal path for a responder involves no sign-up at all. It is also one of the most useful signals for telling a legitimate request from an attempted scam. ## What you will be asked for **En corto** - Confirming it is you, usually with a code sent to your email or phone. - That is not registering: it is checking once that the right person opened the link. - And it creates no account and leaves you signed in to nothing afterwards. > [!WARNING] > A reasonable worry worth clearing up: **having no account does not mean nothing is recorded**. What you upload is logged — what, when and through which link — and that is precisely what protects both sides when someone later says «I did send that». No user account is convenience for you, not absence of a trail. **What if I want to see later what I sent?** Ask whoever requested it. While the link is live you can sometimes go back in. **Will you send me marketing?** Answering a request signs you up to nothing. **Can I open it on my phone?** Yes, and most people do: the link works the same. ## Ejemplos **A supplier receives the request and spends half an hour looking for where to register.** - Goes straight in through the link and uploads the documents → The reply arrives the same day instead of waiting on a sign-up that does not exist. **A screen asks them to create an account to «access the documents».** - Stops, checks where the link came from and calls their contact → A link that did not follow the normal path is discarded before any details are entered. **A supplier saves the link and months later wants to get back in.** - Asks whoever sent it for a fresh link → Access expires by design rather than staying open forever. **A company wants its supplier to have a user account to see the history.** - Grants portal access if it is genuinely needed → Answering once is kept distinct from working inside. **Somebody forwards the link to a colleague so they can upload instead.** - Checks first that it may be shared within their company → Whoever holds the document uploads it without breaking the trail. **A signer believes they need to install something to sign.** - Signs from the browser, with nothing to install → The signature is resolved there and then, from any device. **A link arrives and it is unclear whether it is legitimate.** - Checks with the known contact before opening it → Verification happens through a channel other than the link itself. --- --- id: KB-PS-022 url: https://app.codecontract.io/help/getting-started/i-dont-know-what-im-supposed-to-do-now idioma: en categoria: primeros-pasos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-PS-011, KB-TL-008] citadoPor: [KB-PS-021] --- # I don't know what I'm supposed to do now _Nearly always the answer is: nothing. What is waiting on someone else needs nothing from you until they reply._ **Responde a:** what do i do now · i created the process now what · im lost and dont know how to continue · what is left to finish **If what is open is waiting on someone else, you have nothing to do.** It sounds obvious and it causes half the feeling of being lost: people hunt for a task of their own when all that is missing is a reply from outside. ## How to tell whose turn it is | State | Is it yours? | | --- | --- | | Requested and awaiting a reply | No. Wait, or chase | | Something uploaded and unreviewed | **Yes. This one is yours** | | Complete | No, unless you want to close it | | Stalled for a while | Yes, but the action is a reminder, not a redo | > [!IMPORTANT] > **There is only one question you need to answer each morning: is anything waiting on me?** Everything else —what is in progress, what is closed, what someone else has to send— does not need your attention today. If that question is hard to answer at a glance, that is the problem to solve, and it is not a personal organisation problem: you are looking at the wrong list. ## If you have just started and do not know where to begin 1. **Finish one whole thing before opening a second** — One small completed process teaches more than three half-done. 2. **Send it to someone friendly first** — A colleague or a supplier you know well: mistakes surface at no cost. 3. **And look at what reaches them** — Nothing else puts how it works into your head faster. > [!WARNING] > What throws people most at the start is not the tool: **it is waiting for a confirmation that is not coming**. Many things finish without ceremony — it sends, it uploads, it saves, and that is it. If you are stuck waiting for a «done» that never appears, check the state in the list: it is almost always already done, and what is missing is a reply from outside. **How do I know if I am forgetting something?** Look at what is waiting on your side. The rest is not yours. **Do I have to review everything daily?** No. Only what changed since yesterday. **What if nobody ever replies?** Then the action is yours: chase, and by another route. ## Ejemplos **Someone reviews all twenty open files each morning looking for something to do.** - Looks only at what is waiting on their side and lets the rest run → The daily review drops from half an hour to two minutes without missing anything. **The first process goes to an unfamiliar supplier who does not reply for a week.** - Tries it first with a colleague or a supplier they know well → Design flaws surface in a day without burning a client's patience. **There are twenty open files and none seems to move.** - Filters by what is waiting on your side → You are left with a short list of things that really depend on you. **A file has not moved in weeks and nobody noticed.** - Lets it flag anything stalled too long → What is stuck surfaces by itself rather than being hunted. **A reminder is resent by hand just in case.** - Checks whether the automatic reminder already went → You avoid chasing the same supplier twice in one day. **A file is closed without knowing whether something was missing.** - Looks at what is outstanding before signing it off → Closing rests on a list rather than an impression. **Somebody new joins and does not know where to start.** - Shows them the view of what is waiting on their side → They know what to do on day one without a full explanation. --- --- id: KB-PS-023 url: https://app.codecontract.io/help/getting-started/when-do-you-need-it-by idioma: en categoria: primeros-pasos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-PR-028, KB-TL-004, KB-PS-021] citadoPor: [KB-PS-018] --- # When do you need it by? _If the request does not say, ask. A specific date is the only thing that turns «whenever» into something that gets done._ **Responde a:** when do i have to send the paperwork · the request has no deadline · how long do i have to reply · is this document request urgent **If no date comes with it, ask — and if you are the one asking, always give one.** A request with no date reads as «whenever», and «whenever» competes on anybody's list against things that do have a day. ## Why the date is missing so often | Reason | What to do | | --- | --- | | It seemed obvious to the requester | Ask: the answer will be specific | | There is no real deadline yet | Agree one anyway. Undated things do not happen | | There is a deadline but it is a third party's | Ask for that one: it is the real driver | | A template was copied without adjusting | Very common. Asking fixes it | > [!IMPORTANT] > **Asking for the date is not a formality: it is what prevents the reminder two weeks from now.** And if it turns out they need it tomorrow, better to know today — the most expensive moment to discover an urgency is once it has passed. The question costs one line and changes your week in either scenario. ## If you are not going to make it 1. **Say so before the date, not after** — The difference between re-planning and looking bad. 2. **Give a specific date of your own** — «Tuesday» works; «as soon as I can» is not plannable. 3. **And send what you do have meanwhile** — It usually unblocks half of it for them. > [!WARNING] > What lies behind almost every outside rush: **whoever is asking usually has a deadline they did not set either**. An audit, a client of theirs, an onboarding date. Asking «what is that date driven by?» helps both sides: sometimes you discover there is real slack, and sometimes you discover there is none at all and they were asking far too gently. **Can I ask for more time?** Nearly always, if you ask before it lapses and offer an alternative date. **What if they never give me a date?** Set one yourself and say it. Nobody will argue. **Do reminders mean I am late?** Not necessarily. They mean the request is still open. ## Ejemplos **A request arrives with no date and sits at the bottom of the list for three weeks.** - Asks for the date on receipt and notes it down → The request enters the list with a day instead of competing against things that have one. **You are not going to make the agreed date and say so the day after it passed.** - Flags it before it lapses and proposes a specific date → The other side re-plans instead of discovering the delay with no slack left. **The request says «whenever you can» and nobody prioritises it.** - Puts a specific date in the request itself → It enters the other side's list with a day attached. **Something is requested for «this week» without naming a day.** - Writes the full date rather than a relative reference → There are no two readings of the same phrase. **The supplier delivers late and says they did not know it was urgent.** - Explains in the notice what depends on that date → The urgency is understood without a phone call. **Nobody knows which requests fall due this week.** - Checks what is due and acts beforehand → Warning happens before the deadline rather than after. **A date is agreed by phone and later the two versions differ.** - Records the date in the file → What was agreed stops depending on two memories. --- --- id: KB-PS-003 url: https://app.codecontract.io/help/getting-started/your-first-week idioma: en categoria: primeros-pasos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-001, KB-ET-001] citadoPor: [KB-PS-006, KB-ET-009, KB-PS-007, KB-PS-010, KB-PS-011, KB-PS-013, KB-PS-005] --- # Your first week _What to do in the first days so the platform actually earns its keep, in order._ **Responde a:** where do i start with code contract · what do i do on day one · how do i get the platform running · quick start guide The commonest mistake when starting is trying to set everything up before using anything. It takes two weeks, gets abandoned at the first obstacle, and nothing has been gained. This order does the opposite: something working on day one. **En corto** - One real process end to end beats ten half-built. - Invite the team when there is something to show them. - What you do not use in week one, you probably do not need. ## Day 1 — a real case Take something that is on your desk today: a supplier to chase for paperwork, a contract to sign. Do it end to end on the platform, even if it is slower than email that first time. It is the only thing that really teaches how the pieces fit. ## Day 2 — turn it into a template Save what you just did as a process. From then on the second case takes two minutes. ## Days 3 and 4 — the team Now invite people. Bring them in with something that already works in front of them, not an empty screen. Give each of them what they need and nothing more: someone who only looks does not need to be able to delete. ## Day 5 — what slips through Look at which of your own documents expire and set the dates. That is what turns the platform into something that warns you, rather than a filing cabinet you have to go and check. > [!NOTE] > If by the end of the week you have one repeatable process and three people using it, you are on track. If you have twelve processes and nobody inside, go back to day one. **How long until it is running?** One real case, the first afternoon. The whole team, a week. **Do I need IT help?** Not to start. Only to connect email to your own domain, and that can wait. **What if I set something up wrong?** Everything can be changed later. Nothing from day one is irreversible. ## Ejemplos **A twelve-person company starts on a Monday.** - Monday: chases a real supplier for paperwork - Tuesday: saves it as a process - Thursday: three colleagues join - Friday: sets expiry dates on their insurance → The following Monday the second supplier takes two minutes and nobody needed training. **A company spends the first week configuring and asks nobody for anything.** - Picks a real process that already hurts and launches it on day one - Adjusts the configuration around whatever comes up → Configuration is decided from real cases rather than assumptions. **The whole team is invited on day one and nobody knows what to do.** - One person starts with a process of their own - The others come in once there is something to show them → Whoever joins finds something working rather than an empty tool. **On day three the same thing must be requested from another supplier and it is rebuilt from scratch.** - Saves the first process as a template - Launches the second supplier from it → The second request takes two minutes instead of half an hour. **Nobody knows whether the supplier received the request.** - Checks the status of each request sent - Lets the reminders go out on their own → You stop emailing to ask whether it arrived. **The first week ends with nothing to show management.** - Closes one complete file, however small - Shows it with its trail and its dates → The decision to continue is taken on something done rather than a promise. --- --- id: KB-PS-004 url: https://app.codecontract.io/help/getting-started/which-module-do-i-need idioma: en categoria: primeros-pasos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-001, KB-GL-001] citadoPor: [KB-PS-008, KB-PS-014, KB-GL-002] --- # Which module do I need _Trackline, Consigne or SmartCheck: which one solves what you have in front of you._ **Responde a:** difference between trackline consigne and smartcheck · which module do i use to sign · what each part of the platform does · do i need to request documents or sign them The three modules do different things with the same kind of material. The question that separates them is simple: is the document missing, does it need signing, or do you need to prove it existed? | If what you need is… | Module | Example | | --- | --- | --- | | Someone to send you something you do not have | Trackline | Asking a supplier for their insurance and certificates | | Someone to sign something you already have | Consigne | A contract, an amendment, a consent form | | To prove something existed and said this | SmartCheck | A report, photos of a delivery | ## Using two is normal Supplier onboarding starts in Trackline — you ask for their paperwork — and ends in Consigne — they sign the agreement. You do not have to choose: they chain together inside the same case. ## The commonest confusion "I have a contract I want signed and I also need them to send me their insurance." That is both things: Consigne for the signature, Trackline for the insurance, in the same process. > [!NOTE] > If in doubt, start with whatever is most urgent. All three share the same contacts and the same documents: nothing you do in one has to be redone in another. **Do they have to be bought separately?** They share the account, contacts and balance. They are not isolated products. **Can I use only one?** Yes, many people start with one and add the others when they need them. **Can a document signed in Consigne be certified?** The signature already carries its certified date; certifying it separately is unnecessary. ## Ejemplos **A company wants subcontractors to sign an agreement and also send documentation.** - Builds a process that requests the paperwork - Adds signing the agreement as the final phase → The subcontractor does it all from one link, without knowing two modules are involved. **All that is needed is for a hundred suppliers to keep their paperwork current.** - Sets up the request process and lets it chase on its own → It is solved with one module and no decision about the other two. **A document must be signed with someone outside and there is nothing else to request.** - Sends the document for signature and follows each signer's status → The signature closes without building a document process around it. **Proof is needed that something existed on a given date.** - Seals the document and keeps its dated trail → The proof stops resting on anyone's word. **A company does not know where to start and wants to try all three at once.** - Picks the process that consumes most time today - Starts with the module that covers it → The first result arrives before anything permanent is decided. **You start with one module and months later need another.** - Adds the second over the same files → Nothing already running has to be moved. --- --- id: KB-PS-005 url: https://app.codecontract.io/help/getting-started/getting-your-team-to-actually-use-it idioma: en categoria: primeros-pasos subcategoria: recursos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-ET-005] citadoPor: [KB-PS-013, KB-CR-015, KB-PS-015, KB-PS-017] --- # Getting your team to actually use it _The part that is not technical and decides whether any of this works._ **Responde a:** the team is not using the tool · how to train my team · adoption of a new tool · they still use email for everything Almost every abandoned tool worked fine. What fails is the moment someone is in a hurry and the fast route is still to send an email. If that route stays open, it gets used. **En corto** - Start with one convinced person, not the whole team. - One complete case teaches more than a training session. - While email still works for the same thing, email is what people will use. ## What works 1. **One person, one process, two weeks** — Have someone genuinely use it for their own work and have it pay off. That convinces more than any demo. 2. **Let that person tell it** — A colleague explaining how they saved three days beats a training session. 3. **Close the old route for that process** — "Supplier onboarding goes through here" has to be a decision, not a suggestion. 4. **Add the next process** — Once the first is habit, not before. ## What does not work - Training everyone on the same day about something nobody has used. - Building twelve processes before one is in use. - Letting each person decide: you end up with two systems and neither complete. > [!WARNING] > If someone goes back to email, ask why before repeating yourself. There is almost always a concrete reason — a missing permission, a process that did not cover their case — and fixing it convinces better than restating the rule. > [!NOTE] > The sign it has taken hold is not that everyone signs in: it is someone saying "we set this up in there, right?" without being prompted. **How long until it sticks?** One process, a few weeks. A whole department, a few months. **Is formal training needed?** Rarely. A real case, accompanied, teaches more. **What about someone who refuses entirely?** Usually it is whoever moves the most paper. Start by making one concrete thing easier for them. ## Ejemplos **A company trains twenty people in one session and two months later nobody uses it.** - Starts again with one person and supplier onboarding - Three weeks later she explains it at the team meeting - Onboarding is decided to go through there → Three months on, twelve people use it, with no training session at all. **The tool is announced at an all-hands and nothing happens afterwards.** - Picks one specific process and one person responsible - Makes the announcement once it already works → A real change is communicated rather than an intention. **Everyone keeps requesting documents by email because it feels faster.** - Makes the new way the most convenient for whoever requests - Stops accepting the old channel once the new one works → The change holds without weekly nagging. **Whoever drives it goes on holiday and usage fades.** - Shares the process between two people from the start → Usage does not depend on one person being around that month. **The team sees it as one more tool to learn.** - Starts with what removes work, not with what adds control → The first experience is a saving rather than an obligation. **Nobody knows whether it is being used.** - Looks at which processes get launched and which stall → The adoption conversation happens with data. --- --- id: KB-ET-006 url: https://app.codecontract.io/help/your-workspace/searching-and-actually-finding idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-004, KB-MA-002] citadoPor: [KB-PR-007, KB-TD-005, KB-TD-007, KB-TD-010, KB-ET-015] --- # Searching and actually finding _Search by what the document says, not by where you think you filed it._ **Responde a:** i cannot find a document · search inside pdf content · search by tax id or registration · filter documents by date Most people search by navigating: they open the folder they think they remember and work down. It is slow and it fails exactly when someone else filed it. Searching by what the document says always works. **En corto** - It searches inside documents, not only their names. - Accents and capitals make no difference. - A tax ID, a registration number or a policy number is the best possible search. ## What to search for to find it sooner | Instead of… | Search… | | --- | --- | | "contract" | The company name or its tax ID | | "insurance 2024" | The policy number | | "the one for that site" | The site address | | "what Juan sent" | What the document says; the sender is a filter, not a search | ## When too many results come back Filter by date, document type or owner. It is faster than refining the search with more words, which usually yields nothing at all. > [!NOTE] > If you search for something three times in a week, it is not a search problem: that document deserves to be linked from where you work. > [!WARNING] > You only find what you can see. If a colleague swears they uploaded something and it does not appear for you, check permissions before searching harder. **Does it search inside scanned documents?** Yes, if they were read on upload. **Can I search by an extracted value?** Yes, and it is the most precise: expiry dates, amounts, identifiers. **Will it find things if I type without accents?** Yes, and with or without capitals. ## Ejemplos **Someone needs a supplier's insurance and does not know who filed it.** - Searches the supplier's tax ID → Their four documents come up, insurance included, without opening a single folder. **A search by file name returns nothing.** - Searches by something the content says → Finding stops depending on what it was called. **The search returns hundreds of results.** - Filters by file, date or type → You reach the specific one. **A document exists and one person cannot see it.** - Checks whether they have access to that file → A search fault is ruled out. **A field is searched for and it was never extracted.** - Adds that field to the extraction → Search finds what is needed. **Old scans do not appear in searches.** - Checks whether they were processed on upload → The history becomes searchable. --- --- id: KB-ET-008 url: https://app.codecontract.io/help/your-workspace/inviting-an-outsider-into-your-account idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-AD-002] citadoPor: [KB-CL-001, KB-CL-008] --- # Inviting someone from outside _Accountants, auditors and advisers: what to give them and what not to._ **Responde a:** give my accountant access · invite an external auditor · temporary access for a collaborator · share with someone outside the company Sooner or later someone outside needs to see something: the accountants, an auditor, a lawyer, a one-off collaborator. The temptation is to make them an administrator so they stop asking; it is also the costliest mistake. ## What to give them, by role | Who | What they need | What they do NOT need | | --- | --- | --- | | Accountants or advisers | Read access to their scope, and downloads | Creating processes, deleting, seeing other clients | | Auditor | Read access limited to the audited scope | Anything more, and only for a limited time | | Lawyer | The specific case for the matter | The rest of the organisation | | One-off collaborator | The team or project they work on | Organisation settings | ## Three rules - Never administrator. An outsider must not be able to change your permissions or settings. - Scoped to their part, not everything. "Read-only" across the whole organisation is still too much. - With an end date. When the engagement finishes, access goes that day, not when someone remembers. > [!IMPORTANT] > If you hold documentation for clients who compete with each other, a badly scoped external access is not an internal slip: it is a third party's information seen by someone they never authorised. > [!NOTE] > Scoped read access usually beats emailing the documents: it leaves no loose copies and it records what was looked at and when. > [!WARNING] > Review external accesses once a quarter. They are the most forgotten because they are not part of your team and nobody misses them. **Can I grant access for a few days only?** Yes, and it is recommended for audits. **Does an external user consume anything?** Viewing and downloading do not consume. **Do they know I am watching?** Their accesses are logged like anyone else's; it is not surveillance, it is the same treatment. ## Ejemplos **A company gives its accountants administrator access to avoid emailing documents.** - Changes it to read access scoped to tax matters - Reviews external accesses each quarter → The accountants work exactly as before and can no longer change the company's configuration. **Somebody who only had to provide one paper is invited as a user.** - Sends them a link instead of an invitation → No licence is consumed for a one-off contribution. **An external party needs to see several files for months.** - Grants limited access to what they need → They work without seeing the rest. **The external party finishes and their access stays active.** - Revokes access on completion → Access reflects who is collaborating today. **Nobody knows which external parties have access.** - Checks the list of external access → The picture exists without asking. **An external party asks for more access than they need.** - Grants the minimum for their task → The scope matches the work. --- --- id: KB-ET-009 url: https://app.codecontract.io/help/your-workspace/what-an-organisation-is idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-003, KB-ET-004] citadoPor: [KB-ET-014, KB-ET-019] --- # What an organisation is _Your company's space: what it holds and what never leaves it._ **Responde a:** what is an organisation on the platform · is my data mixed with other companies · switch organisation · what my account contains An organisation is your company's space: inside it are your documents, contacts, processes, team and balance. Outside it there is nothing of yours, and nothing inside crosses into another organisation. **En corto** - An organisation's data is seen only by that organisation. - Everything you create — contacts, templates, cases — lives inside it. - One person can belong to several and switch between them with nothing mixed. ## What it holds | What | Shared within the organisation | | --- | --- | | Documents and cases | According to each person's permissions | | Contacts | Yes | | Templates and processes | Yes | | Credit balance | Yes, one for everyone | | Settings and branding | Yes | > [!IMPORTANT] > Separation between organisations is hard, not a setting: there is no permission that lets someone in another organisation see yours. It is what allows one firm to serve two competing clients. ## When you need more than one Almost never at the start. If you have several legal entities but the same team works across all of them, one organisation with separate teams is easier and loses nothing. Several organisations are for when the people must not see each other. > [!NOTE] > Splitting later is easier than merging. Start with one: moving documents between organisations is manual work, and splitting a history is what makes nothing add up afterwards. **How do I know which one I am in?** It shows at the top. If something is missing, check that before permissions. **Can I be in two?** Yes, and switch between them. **Is the balance shared between organisations?** No. Each has its own. ## Ejemplos **A firm worries that two competing clients' documents will end up mixed.** - Confirms each client is a team within their organisation - Scopes permissions per team → Each account manager sees only their clients, and no client sees anything of another's. **An organisation is created for every project.** - Uses projects inside one organisation → The structure does not multiply. **Two group companies share an organisation.** - Separates each into its own → Each one holds its own. **Nobody knows which organisation a file sits in.** - Checks which organisation created it → You reach it without searching them all. **A user cannot see what they expect.** - Checks which organisation they are working in → The confusion clears in a minute. **Something is shared from the wrong organisation.** - Shares from the file's owning organisation → The trail points at the right party. --- --- id: KB-ET-010 url: https://app.codecontract.io/help/your-workspace/reviewing-permissions-once-a-year idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-AD-003] citadoPor: [KB-ET-013, KB-AD-014] --- # The annual permission review _Half an hour that prevents the problem nobody sees coming._ **Responde a:** review who has access to what · internal permission audit · clean up old accesses · someone has more permissions than they need Permissions do not break suddenly: they accumulate. Someone changes role and keeps the old access, someone gets "temporary" access to a project and nobody removes it, an external auditor comes in and is still there two years later. None of that announces itself. ## The four questions 1. **Is everyone on this list still here?** — It is what comes up most, and the easiest to fix. 2. **Did anyone change role and keep the old access?** — A promotion leaves permissions that no longer match what they do. 3. **How many administrators are there?** — It should be two. If it is seven, nobody feels responsible for anything. 4. **Any external access still open?** — Accountants, auditors, one-off collaborators. They are the most forgotten because nobody misses them. ## What usually turns up | Finding | Frequency | What to do | | --- | --- | --- | | Accounts of people who left | Nearly always | Close them that day | | Permissions inherited from a previous role | Very common | Adjust to what they do now | | Too many administrators | Common | Reduce to two | | An external with months-old access | Common | Remove it; if needed again, grant it again | > [!IMPORTANT] > Removing a permission is not distrust, and it is worth saying so when you do it. Surplus access is a risk to that person too: if their account is compromised, what the intruder takes is everything they could see. > [!WARNING] > Do not run the review on a Friday afternoon. If you remove something by mistake, someone cannot work and nobody can fix it until Monday. > [!NOTE] > Half an hour a year. Against the cost of discovering during an audit that six accounts of departed staff are still open, it is the best effort-to-result ratio in the whole of administration. **Should people be told?** If it affects what they do, yes, and one sentence suffices. **Is the change recorded?** Yes, who made it and when. **Can I see who has never signed in?** The log shows it, and it is usually the first place to look. ## Ejemplos **A company runs its first permission review after two years.** - Closes six accounts of people who left - Reduces administrators from nine to two - Removes access granted for an audit eighteen months ago → Half an hour closes nine open doors nobody knew were there. **Nobody has reviewed permissions in years.** - Schedules the annual review → Access reflects today's organisation. **People leave and their access stays active.** - Cross-checks the user list with joiners and leavers → The active accounts are the right ones. **There are permissions nobody remembers granting.** - Reviews case by case with the owner → What remains has a reason. **The review happens and nothing is recorded.** - Records what was reviewed and what changed → The review is demonstrable. **An auditor asks about access control.** - Shows the review with its date → The control moves from assertion to evidence. --- --- id: KB-ET-012 url: https://app.codecontract.io/help/your-workspace/where-everything-lives idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-006, KB-CC-003] citadoPor: [KB-TD-005, KB-TD-012, KB-PR-026] --- # Where does everything live? _The map of what lives where, so you stop looking in the wrong place._ **Responde a:** where are documents stored · where do i see what i sent · i do not know which screen to look at · difference between case document and contact Most of the time lost when starting is not learning how to do something: it is finding where it is. Here is the map, and with it nearly every navigation question disappears. | If you are looking for… | It is in… | And it is organised by… | | --- | --- | --- | | A specific document | The case it arrived in, or search | Its content: search by tax ID or number, not filename | | What you asked someone for | That matter's case | Who is involved and what they are missing | | What you sent for signature | The request, under signatures | Its state: sent, opened, signed | | A company's details | Its contact record | The organisation, with its people inside | | What you signed for others | Your participations | The other party, not you | | What is stuck | The list, filtered by age | Whatever has waited longest | > [!IMPORTANT] > The commonest confusion is between **case** and **document**. The case is the matter — onboarding a supplier, a site; the document is one of the things inside it. If you cannot find a loose document, look for the matter it belongs to. ## The rule that saves most time Search by what the document says, not by where you think it is. Search looks inside content, so a tax ID, a registration or a policy number finds in a second what navigating takes half an hour to reach. > [!WARNING] > If you cannot find something someone swears they uploaded, check two things before searching harder: which organisation you are in, and whether you have permission to see it. Those are the two commonest causes and neither is a search problem. > [!NOTE] > What repeats weekly deserves a saved filter. Navigating to the same place five times is the sign it should be one click away. **Can a document be in two places?** It is linked rather than duplicated, and takes no double space. **Where do I see what expires?** By filtering on expiry date. **What about what I deleted?** It depends on your retention policy; do not count on recovering it. ## Ejemplos **Someone new spends twenty minutes looking for a certificate by filename.** - Searches the supplier's tax ID → Finds it in seconds, and from then on always searches by content. **Nobody can find a document they know exists.** - Searches by content rather than by folder → You get there without walking the structure. **Each person files things wherever they think best.** - Agrees where each document type goes → Anyone reaches the same place. **A file exists in two places.** - Checks which is the good one and merges → There stop being two versions. **Somebody new does not know where to look.** - Shows them the structure and the search → They find their way on day one. **What is being looked for sits in somebody's inbox.** - Uploads it to the file on receipt → Information lives where people look. --- --- id: KB-ET-013 url: https://app.codecontract.io/help/your-workspace/when-someone-leaves idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-003, KB-ET-010] citadoPor: [KB-ET-005] --- # When someone leaves _The day they go, and the two weeks before. In that order of importance._ **Responde a:** employee leaving access removal · what to do when someone leaves the team · handover before a departure · revoking access for a leaver Someone leaving is nearly always treated as an access matter: remove the account and done. That is the urgent part, but it is not what will cost you money three months from now. ## The two weeks before 1. **Have them move conversations into the files** — Whatever stays in their inbox goes with the account, and that is where commitments live. 2. **Have them write down the why of the odd cases** — The exceptions only they knew: who is billed differently, who must be phoned. 3. **Make clear who picks up each matter** — By file, with a name. "The team" is not an owner. 4. **And review their tasks and alerts** — If they were in their name, nobody will look at them after they go. > [!IMPORTANT] > The first point is 80% of the value. Most knowledge lost in a departure was never in anyone's head: it was in an email nobody else can open. ## The day itself | What | When | Detail | | --- | --- | --- | | Withdraw access | That same day | Not the following week | | Close their sessions and devices | At the same time | Removing the account does not close what is already open everywhere | | Reassign what was in their name | Before withdrawing | Otherwise it is orphaned and nobody sees it | | Record the date | In the log | It is what gets checked if something happened afterwards | > [!WARNING] > The third row must happen **before** the second. Withdraw access first and their tasks, alerts and files are left without an owner, and nobody notices until something expires. ## What is not deleted **En corto** - Their activity history: it is part of the record and stays untouched. - The documents they uploaded: they belong to the organisation, not to them. - And what they signed: still valid and verifiable. What is withdrawn is access, not the trace. That distinction is what lets you answer years later who did what, even though the person is gone. > [!NOTE] > If the departure is contentious, reverse the order: access first, handover with whatever exists after. And review the activity log for the preceding days, which is exactly what it is there for. **What if they come back later?** Grant access again; do not leave it open just in case. **Does it free their seat?** Yes, withdrawing access makes it available for someone else. **Can I see what they took?** You can see what they consulted and downloaded, which is what the activity log records. ## Ejemplos **A company withdraws access on the leaving date and two months later an insurance policy lapses.** - Reassigns tasks and alerts before withdrawing access on the next departure - Asks for conversations to be moved into the files → The successor sees what is due and nothing is left without an owner. **Somebody leaves with open files in their name.** - Reassigns their files before their last day → No third party is left waiting. **Their mailbox is closed and conversations go with it.** - Stores what matters in the files beforehand → The information outlives the departure. **Their access stays active weeks later.** - Revokes access on their last day → The account reflects who works here. **Notices keep going to their address.** - Changes the recipient on the files → Notices reach somebody who exists. **There is a wish to delete their past signatures.** - Keeps the record of what they did → The history stays true. --- --- id: KB-ET-014 url: https://app.codecontract.io/help/your-workspace/one-organisation-or-several idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-007, KB-ET-009] citadoPor: [KB-CD-012] --- # One organisation or several? _The hardest decision to undo, explained with the three criteria that matter._ **Responde a:** separating group companies on the platform · one organisation per legal entity or a single one · how to organise several brands · splitting by branch or not If you have several legal entities, brands or branches, at some point you must decide whether they go together or apart. Decide early: moving documents and files between organisations later is work, and some things cannot be moved. ## The three criteria | Question | If yes | If no | | --- | --- | --- | | Must someone NOT see the other's material? | Separate | Together | | Do they invoice and contract separately with third parties? | Probably separate | Together | | Does the same person work across both daily? | Together, with teams | Separate | > [!IMPORTANT] > The first overrides the others. If there is information that must not cross — for competition reasons, a partner agreement, or regulation — separation is the answer even if it is more awkward to run. ## What changes with the choice 1. **Separate: real isolation** — Nothing is visible across. Including contacts, templates and reports. 2. **Separate: duplicated administration** — Configuration, users and balance for each. That is the price. 3. **Together: a single picture** — Group-wide reporting and shared work without switching. 4. **Together: separation via permissions** — Works well for branches, not for different partners. > [!WARNING] > The most commonly mis-decided case is branches. Five organisations get created "so each sees its own", and a month later management wants a consolidated report that must now be assembled five times by hand. That is what teams and permissions were for. ## If you already chose wrong **En corto** - Merging two organisations is work, but it can be planned. - Splitting one in two is easier done early, with little inside. - And in either case, the first step is exporting and knowing what you have. It is not irreversible, but it is one of the expensive ones. Half an hour of thought at the start saves weeks later. > [!NOTE] > Switching organisation happens from the same control at the top, without logging in again. And whoever has access to several has it explicitly: nothing becomes visible by accident. **Can users belong to several?** Yes, with access granted in each. **Is the balance shared?** Each organisation holds its own; if that complicates things, it is an argument for merging. **What about a franchise?** Usually separate, with head-office access where appropriate. ## Ejemplos **A group with five branches creates one organisation per branch.** - Checks that nobody must be blocked from another's material - Merges them and separates with teams and permissions → Management gets the consolidated report and each branch still sees only its own. **An organisation is created per branch office.** - Uses projects or folders inside one → The structure does not multiply without reason. **Two companies share an organisation and everything mixes.** - Separates each into its own → Each one holds its own. **Reports have to be added up by hand across organisations.** - Considers whether separating them was really needed → The decision is revisited against real use. **One person works in both and duplicates accounts.** - Grants access to both with one account → Duplicate passwords disappear. **They were separated out of caution and now it gets in the way.** - Revisits the decision with usage data → The structure matches how people work. --- --- id: KB-ET-015 url: https://app.codecontract.io/help/your-workspace/naming-things-so-you-can-find-them idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-004, KB-ET-006] citadoPor: [KB-ET-018] --- # Naming things so you can find them _Three naming rules worth more than any folder structure._ **Responde a:** how to name files · file naming convention · organising project names · criteria for naming documents People argue a lot about how to organise folders and hardly at all about how to name things, when it should be the other way round: with good names you find everything even with a mediocre structure, and with bad names no structure saves you. ## The three rules 1. **Start with what distinguishes it** — If you search by client, the client goes first. If by site, the site. 2. **Include the identifier people actually use** — The order number, the registration, the site code. The one said out loud, not a new one. 3. **And the date in sortable format** — 2026-08 sorts properly; August 2026 does not. Only if the date matters. > [!IMPORTANT] > The second pays off most and is broken most. If in the office the job is "the port one" and in the system it is "EXP-2026-0448", there are two vocabularies and someone must translate each time. Include both: nobody ever regretted a slightly longer name. ## What not to include | Not this | Why | | --- | --- | | "final", "definitive", "good" | A "final2" always appears | | The author's initials | It stops meaning anything when they leave | | Abbreviations only one department understands | Nobody else will ever search for them | | The version, if the system already tracks it | It duplicates information and drifts out of sync | > [!WARNING] > The first row seems trivial and is not: "contract_final_v3_reviewed.pdf" lives alongside "contract_final_good.pdf" and nobody knows which governs. If there are versions, mark them as versions; the name is not the place. ## And with contacts **En corto** - The full legal name, not just the trading nickname. - The tax identifier, the only thing that does not change. - And one record per company, even with several branches. Duplicate contacts are the number one cause of "I can't find it", and they almost always come from writing the same name three different ways. > [!NOTE] > None of this is needed if you search inside documents, which works fine with bad names. But names appear in listings, and that is where the time actually goes. **Should old material be renamed?** No. Apply it to new material; old material is found by content. **What if each department wants its own?** Agree only on the shared identifier; the rest can vary. **Are automatic codes any good?** Yes, but alongside the human name: a bare code forces translation. ## Ejemplos **A team has three records for the same supplier, spelled three ways.** - Unifies by tax identifier and uses the full legal name → Searches return one record and the supplier's history stops being split. **Files are named with acronyms only one person understands.** - Uses names anyone on the team understands → Finding stops depending on one person. **Two files have nearly identical names.** - Adds what distinguishes them to the name → Nobody works on the wrong one. **The name includes a date in three different formats.** - Agrees one format and applies it → Alphabetical order becomes useful. **A search by name returns nothing.** - Searches by content rather than name → The name stops being the only route. **Each person names things their own way.** - Agrees the convention and writes it down → The archive is readable for everyone. --- --- id: KB-ET-016 url: https://app.codecontract.io/help/your-workspace/the-auditor-role-looking-without-touching idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-AD-011, KB-ET-017] citadoPor: [KB-ET-021] --- # The auditor role: looking without touching _For whoever has to review and should not be able to change anything, not even by accident._ **Responde a:** read-only access · auditor role on the platform · let someone review without editing · access for an external auditor Some people come in to check, not to work: an external auditor, your accountants, a quality manager from your client, a partner who wants to see how things are going. Giving them the same role as an operator is convenient on day one and irritating for the rest of the year. ## Why a read-only role is worth it | With an editing role | With an auditor role | | --- | --- | | They can change something by accident | They cannot, and that reassures both sides | | Their actions blend in with the team's | What they do stands out in the log | | You have to trust they will not touch | No trust needed: they cannot | | If they do touch something, it is awkward to explain | Their review does not alter what is reviewed | > [!IMPORTANT] > The fourth row is what really matters in an audit. If the reviewer can modify, any later difference invites the awkward question of whether they caused it. A role that cannot write removes that doubt permanently, and protects the auditor as much as you. ## What someone with that role can do **En corto** - See the files and documents you give them access to. - Consult history and check dates. - And download what they need, if you allowed it. That is exactly what they need to do their job. If at some point they must contribute something — a report, minutes — better they send it and you upload it: the file keeps a single owner. > [!WARNING] > The nuance that sometimes surprises: **read-only is not invisible**. What they consult is recorded in the activity log like any other action, with their name and the time. That is desirable — it lets you answer years later who saw what — but tell whoever comes in, especially an outsider. It is not surveillance: it is the same traceability required of everything else. ## When NOT to use it 1. **If that person will supply documentation** — Then they are not a reviewer: they are a participant, and there are better routes. 2. **If they only need to see one document** — No access needed: send it by their link. 3. **And if it is someone on your team complaining about the role** — They probably need a different one, not an upgrade of this one. > [!NOTE] > Like any outside access, this one is withdrawn when the engagement ends, not when someone remembers. An auditor from two years ago who can still log in is the most awkward finding in your own permissions review. **Does it take a seat?** Yes, it counts as a user while active; hence withdrawing it at the end. **Can they export?** It depends what you enable. If they will export, better known beforehand than discovered after. **What if they need something I did not grant?** Let them ask: widening takes a minute and there is a record of what was widened and when. ## Ejemplos **A company gives its external auditor an editing role so nothing is missing.** - Switches to the read-only role and explains their access is logged - Withdraws access when the report closes → The audit runs with nobody able to question whether the reviewer altered what was reviewed. **An auditor asks for access and is given an editing role.** - Grants read-only access → They look without being able to touch. **There is concern the auditor might change something unintentionally.** - Uses the role that cannot write → The risk disappears. **The auditor finishes and their access stays active.** - Revokes access on completion → Access reflects who is collaborating today. **There is no record of what they consulted.** - Checks the access log → You know what was shown to them. **The auditor only needs to see one part.** - Limits the scope to what is relevant → They see what was asked for and nothing more. --- --- id: KB-ET-017 url: https://app.codecontract.io/help/your-workspace/when-someone-has-two-accounts idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-011, KB-AD-015] citadoPor: [KB-ET-016] --- # When someone has two accounts _The same person logging in with two different emails: why it happens and why to fix it early._ **Responde a:** a user has two accounts · i logged in with another email and see nothing · merging duplicate accounts · changing a user's email It is a small mess that grows: someone logs in one day with their personal email because an invitation landed there, and another day with the company one. To the platform they are two different people, and from then on everything splits in two: what they see, what they have done, and what reaches them. ## How you notice | Symptom | What is happening | | --- | --- | | "I log in and cannot see my things" | They are in the other account's session | | "I do not get the alerts" | They go to the other email | | They appear twice in the user list | There are two accounts, not a display glitch | | The log attributes actions to two names | Which complicates any later review | > [!IMPORTANT] > The fourth row is the most annoying long term and the one nobody sees coming. If the same person has worked six months with two accounts, the history is split: answering "who did this" requires knowing those two identities were one person, and only whoever was there at the time knows that. ## How to fix it 1. **Decide which one is the good one** — Nearly always the company domain: it outlives the person and fits domain-based access. 2. **Move access to that one** — With the same permissions they had on the other, no more. 3. **Withdraw the other, without deleting its history** — What they did stays; what is removed is the ability to keep using it. 4. **And tell them which to use** — That is half the problem: without knowing, they will log in wherever the password is saved. > [!WARNING] > Mind the order: if you withdraw the old account first and that person had tasks, alerts or files in their name, those are left ownerless and nobody notices until something expires. Reassign first, withdraw after — exactly as with a leaver. ## How to prevent it **En corto** - Always invite the corporate email, even if the person asks for their own. - Enable domain-based access if your team shares a domain. - And review the user list occasionally: duplicates are visible at a glance. > [!NOTE] > The external collaborator who works with several companies is a different case: there it is normal to use one email with access to several organisations. That is not two accounts, it is one account with several accesses, and it works as it should. **Can the two accounts be merged?** What moves is the access; each one's history stays where it was generated. **Do they take two seats?** While both are active, yes. Another reason to resolve it early. **What if the good email changes because the domain changes?** Access is updated; no new account is needed. ## Ejemplos **An employee sometimes logs in with her personal email and sometimes with the company one.** - They reassign her tasks to the corporate account before withdrawing the other - They confirm which one she should use → She stops missing alerts and the log attributes her work to one person again. **One person has two accounts and works from both.** - Merges into one and removes the other → The history stops splitting. **Files are spread across their two accounts.** - Reassigns everything to the account being kept → Nothing is left orphaned. **Notices go to the account they do not use.** - Updates the address on the files → Notices arrive where they get read. **An extra licence is consumed.** - Removes the duplicate account → The account reflects the real people. **An account is deleted and its actions vanish from the history.** - Deactivates rather than deletes → The record of what they did is kept. --- --- id: KB-ET-018 url: https://app.codecontract.io/help/your-workspace/when-a-contact-changes-company idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-003, KB-ET-015, KB-ET-020] citadoPor: [KB-ET-019, KB-TL-020, KB-TL-025] --- # When a contact changes company _Editing the card looks like the natural move, and it is exactly what erases the information you needed later._ **Responde a:** a contact has changed company what do I do · change a contact's email · a supplier's address no longer exists · duplicate or edit a contact card It happens constantly: the person you have dealt with for three years moves to another company, or the email domain changes, and someone opens their card and updates it. It looks obvious. The problem shows up months later, when you need to know who something was sent to and which company they answered from. ## What gets rewritten and what does not | Element | What happens when you edit the card | Why | | --- | --- | --- | | Address used from now on | Changes | Which is what you wanted | | Messages already sent | Do not change | They keep the address of the time: that is the proof of who it went to | | Company shown on the card | Is overwritten | The card reflects now; it has no history | | Files they took part in | Still point at that card | And start reading with the new company | > [!IMPORTANT] > The third row is the trap. **An old message keeps the real address it went to, but the card now says that person was always at the new company.** Pull a listing by company and two-year-old work will show up attributed to a firm that had nothing to do with it then. What was sent is right; what is said about it is not. ## The rule, in one line **En corto** - Same person, same role, only the address changes → edit the card. - Same person, different company → new card, and mark the old one inactive. - Different person, same role → always a new card, even if they inherit the mailbox. > [!WARNING] > The third case is the touchiest, and it is not about tidiness but about access: **a link sent to an address keeps working for whoever reads that mailbox**. If the leaver's mail is inherited by their replacement, that person can open things addressed to their predecessor. When a supplier changes contact, anything in flight is resent to the new address rather than trusting the internal forward. ## How to leave it clean without losing the past 1. **A new card with the new company** — And the current address, which is where you will write from now on. 2. **The old one is kept, marked inactive** — It holds everything done through it and stops anyone reusing it. 3. **A note linking the two** — One line on each is enough: whoever searches a year from now will be grateful. 4. **And anything in flight repointed to the new card** — What is closed stays as it was: it reflects what happened. > [!NOTE] > If the person asks you to stop writing to their previous address, that is handled like any other request about their data, and it is separate from keeping the record of what was sent. **Should I delete the old card?** No: everything done through it hangs off it. Mark it inactive. **What if they go back to the previous company?** Reactivate the card from then; that is why it was kept. **Is it worth it for a contact with two messages?** Edit and move on. The rule is for those with history behind them. ## Ejemplos **A supplier's contact moves to another company and keeps dealing with you.** - Creates a new card, marks the old one inactive and links both with a note → The history still says where they answered from then, and new messages go to the right place. **A contact changes company and stays on the old record.** - Updates the contact at their new company → Notices reach the right person. **Emails keep going to their previous address.** - Checks the bounce and updates → Notices stop getting lost. **There is a wish to move their contribution history with them.** - Keeps the history at the company where it happened → The record stays true. **Nobody knows who replaces them at the old company.** - Asks for the new contact before chasing → The request reaches somebody who can act. **The contact is duplicated across two companies.** - Keeps one record per company → Each relationship has its own contact. --- --- id: KB-ET-019 url: https://app.codecontract.io/help/your-workspace/when-the-company-changes-its-name idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-009, KB-ET-018] citadoPor: [KB-ET-001] --- # When the company changes its name _Changing the name takes a minute. What matters is what must not change: everything already issued under the old one._ **Responde a:** we have changed the company name · change of legal name what to update · we were acquired and rebranded · the old logo still shows up It happens more often than you would think: a change of legal name, a merger, a rebrand, or simply the trading name drifting from the registered one. The visible part is fixed in an afternoon. The part that causes trouble months later is the one nobody looks at. ## What gets updated and what stays as it was | Element | Does it change? | Why | | --- | --- | --- | | The name your team sees | Yes | It is today's name | | The branding on what goes out from now on | Yes | Anything leaving from now should carry the new one | | What was already sent and signed | No | It went out that way, and that is the proof of how it went | | Documents with the old name inside | Not rewritten | Replaced by a new version when the issuer issues one | | The name on live contracts | It depends | That is a legal question, not a settings one | > [!IMPORTANT] > The third row is where the temptation must be resisted: **what was sent under the old name must keep saying the old name**. If a document signed two years ago suddenly showed your current legal name, it would stop matching the copy the other party holds — and evidence that does not match the other side's is not evidence. The history is not a snapshot of what you are called today: it is of what you were called then. ## What is worth reviewing the same day 1. **The sender of outgoing messages** — And the domain, if that changes too: it confuses third parties most. 2. **Templates and whatever the recipient sees** — Texts, signatures and anywhere the name was typed by hand. 3. **Automatic notices** — They usually carry the name inside the text and nobody rereads them. 4. **And whatever appears on your public pages** — It is the first thing someone checking you from outside sees. > [!WARNING] > And something worth saying beyond the platform: **your suppliers will keep issuing under the old name for months**. Invoices, certificates and policies will arrive with the old designation until each of them updates their records. It is neither their error nor a gap in your cover, but tell them early — and keep evidence of the change, because it is what explains two correct documents carrying different names. ## If the tax number or the company itself changes **En corto** - That is no longer a name change: it is another entity, and usually deserves its own space. - The previous one's material is kept as it is, because it answers for what it did then. - And what transfers, and how, is a legal decision rather than a configuration task. > [!NOTE] > What a change of name or of company means for live contracts, licences and obligations is for your adviser to determine. **This is only the practical part**: that the new goes out properly and the old stays as it was. **Can I just change the name and be done?** For what goes out today, yes. For what is signed, it is not touched. **What about links I already sent?** They keep working: what changes is the branding on new material. **Should I tell my contacts?** Yes, and early: it saves months of documents in the old name. ## Ejemplos **A company merges and wants everything to show the new name.** - Changes branding on outgoing material and leaves what was sent and signed untouched → New material goes out right and each old document still matches the other side's copy. **The company changes name and documents keep the old one.** - Updates the name on the organisation → What goes out carries the right name. **Old documents carry the previous name.** - Keeps the old ones as they were → The history reflects what it was then. **A client asks whether it is the same company.** - Checks the record of the change with its date → The continuity is explained. **Notices go out with the old name.** - Reviews the templates after the change → What a third party receives is coherent. **The name changes and so does the email domain.** - Updates the contacts and the allowed domain → The team keeps getting in without incidents. --- --- id: KB-ET-020 url: https://app.codecontract.io/help/your-workspace/how-many-contacts-to-keep-per-company idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-003, KB-CC-014] citadoPor: [KB-ET-018] --- # How many contacts to keep per company _One is too few, five nobody maintains. And writing «to the company» is the fastest way to get no reply at all._ **Responde a:** how many people to keep per supplier · writing to info@ or to a person · billing contact and technical contact · duplicates from the same company Address books fill up in two ways and both cause trouble: one record per company with a generic address, or fifteen records for the same company because everyone saved whoever replied to them. The middle ground is not a tidiness question — it decides whether you get answers. ## How many records are really needed | Type of relationship | How many people | Which is the right one | | --- | --- | --- | | Small supplier | One | The person who deals with you, with their address | | Supplier with departments | Two or three | Who signs, who sends papers, who invoices | | Large client | As many as they ask you to deal with | And note what each is for | | A company you barely deal with | One | Even a generic one: it does not deserve maintenance | > [!IMPORTANT] > The detail that changes results: **a generic address is not a contact, it is a door**. Writing to `info@` or `accounts@` lands the message somewhere nobody feels addressed — and what has no addressee has no urgency. It works to introduce yourself and to find the right person, not to ask for something with a deadline. The first serious request is worth far more sent to a name, even one you had to get by phone. ## How to avoid the fifteen duplicates 1. **Search before creating, by the email domain** — It is what groups people from one company. 2. **Store the role, not just the name** — «Ana» says nothing a year from now; «Ana, quality» does. 3. **And merge as soon as a duplicate appears** — Better then than in the clean-up six months from now. > [!WARNING] > Before adding someone because they replied once, check what role they play: **whoever replies is not always the one who decides, and sometimes they were only forwarding**. Saving that person as the main contact sends your next requests to someone with no reason to handle them — the shortest route to no more replies. What to store is who is responsible, even if someone else sends the answer. ## What is worth noting about each one **En corto** - What that person is for: signatures, documentation, invoicing. - Where they actually reply from: email, phone, whichever channel they use. - And if they are the only one: that flags a risk, not tidiness. > [!NOTE] > A company with a single contact and no alternative is a single point of failure — the day they are off, the file stops. You need not store five; it is enough to know who to ask if that one is missing. **Should I save the salesperson who sold to me?** If they will not send documentation, no: it goes stale immediately. **What if the company insists I write to the generic address?** Respect it and note it as theirs. It is how they work. **Is a company record worth having as well as people?** Yes: documents belong to the company, even when a person sends them. ## Ejemplos **A company requests documents from a supplier's generic mailbox and hears nothing for three weeks.** - Calls, gets the name of whoever handles it and sends the request to them → The document arrives in two days, and the record now holds the person who actually handles it. **Only one contact is stored and they are on holiday.** - Records a second contact at the company → The request does not wait on one person. **Fifteen contacts are stored and nobody knows who to write to.** - Marks who the main contact is → The notice goes to the right person. **The contact on record no longer works there.** - Updates on the first bounce → Notices stop getting lost. **Emails go to a generic mailbox and nobody replies.** - Asks for a specific person → The request reaches somebody who can act. **Each team member uses a different contact.** - Centralises the company record → The supplier receives a coherent message. --- --- id: KB-ET-021 url: https://app.codecontract.io/help/your-workspace/who-can-see-what-i-upload idioma: en categoria: espacio-de-trabajo audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-ET-016] citadoPor: [KB-ET-002] --- # Who can see what I upload? _People in your organisation with access to that folder. Not other clients, and not us for the fun of it._ **Responde a:** who sees the documents i upload · can another company see my documents · can everyone at my company see it · who has access to my files **People in your own organisation with permission on that folder can see it, and nobody else.** Another company using the platform sees nothing of yours: each organisation is separated from the rest. ## Who sees what | Who | What they see | | --- | --- | | Colleagues with permission | What is in their folder or project | | Colleagues without permission | Nothing in that folder | | An external participant | Only their own part, through their link | | **Another organisation** | **Nothing. Ever** | > [!IMPORTANT] > **If something is sensitive, the question is not «is it secure?» but «which of my own people have permission?».** The realistic scenario is not a stranger getting in: it is a colleague opening something they should not, because the folder was created with broad access and nobody has reviewed it since. That is fixed by looking at the folder's permissions, not by moving the document elsewhere. ## What is worth reviewing now and then **En corto** - Who still has access among people no longer working on it. - Folders created «for everyone» long ago that now hold delicate material. - And external guests who came in for one matter and are still there. > [!WARNING] > A nuance that usually reassures, and is worth stating in full: **support being able to help you does not mean anyone is reading your documents**. Support staff access is logged, happens to resolve something you asked about, and is not a free wander through your archive. If you ever want to know who has viewed a document, that is a question with an answer: the document's history holds it. **Can my manager see it?** If they have permission on that folder, yes. Same as any shared drive. **Can another of your clients see it?** No. Organisations cannot see each other. **Can I find out who opened a document?** Yes: who did what and when is recorded. ## Ejemplos **Someone hesitates to upload a sensitive document because they do not know who will see it.** - Checks the folder's permissions before uploading and adjusts them if needed → The document goes to the right place instead of staying on someone's desktop. **A folder created «for everyone» two years ago now holds HR paperwork.** - Reviews who has access and narrows it to those who need it → There stop being people with access nobody ever decided to grant. **Something sensitive is uploaded without knowing who will see it.** - Checks who has access to that file → You upload knowingly. **The whole team sees everything by default.** - Limits access according to the work → Sensitive material stays where it should. **It is shared with an external party who sees more than intended.** - Checks the access scope before sharing → They see theirs and nothing more. **You want to know who has opened a document.** - Checks the access log → The question has an answer. --- --- id: KB-ET-011 url: https://app.codecontract.io/help/your-workspace/letting-your-team-join-by-email-domain idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-006, KB-AD-002] citadoPor: [KB-PR-011, KB-AD-010, KB-ET-017] enLaApp: https://app.codecontract.io/settings/organization --- # Letting your team join by email domain _Anyone with a company email joins without an invitation. And why that has a limit._ **Responde a:** let employees join the organisation automatically · automatic signup by email domain · i do not want to invite one by one · domain-based auto-join With twenty people, inviting one by one is a chore. With two hundred, it is a task nobody finishes. The alternative is authorising your domain: anyone registering with a company email joins directly. ## How to enable it 1. **Go to Settings → Organisation.** 2. **Enter your email domain.** 3. **Tick that joining by domain is allowed.** > [!IMPORTANT] > It only works with your own domain. It cannot be enabled with gmail.com, hotmail.com or any other free email, and that is blocked deliberately: authorising gmail.com would mean anyone in the world with a Gmail account joins your organisation. That is a hole, not a limitation. ## What to decide first | Question | Why it matters | | --- | --- | | Should everyone with a company email join? | In some companies yes; in others whole departments have no business here | | With what permissions? | Joining is not the same as joining as an administrator | | What happens when someone leaves? | If their email is deactivated they can no longer join; if not, they still can | > [!WARNING] > This does not replace removing leavers. If your company keeps email active for a while after departure, that person can still get in. Removal is done the same way. > [!NOTE] > If you have corporate sign-in, this is redundant: there, who gets in and who stops is decided by your identity system, which is more precise. **Can I have several domains?** The authorised domain is one; for multi-brand cases, ask. **Do they join as administrators?** No. They join with the basics and permissions are adjusted afterwards. **Can I disable it later?** Yes, and those already in stay; new people stop joining. ## Ejemplos **A 180-person company wants everyone able to look things up without individual invitations.** - Authorises its corporate domain - Sets the joining profile to read-only → People join by themselves and broader permissions are granted by hand, which are few. **Each joiner is invited by hand, one by one.** - Allows entry by corporate domain → Onboarding stops being a manual formality. **Somebody from a similar but unrelated domain gets in.** - Checks which domains are allowed → Only the right people get in. **A supplier with an address on the same domain gets in unintentionally.** - Reviews the domain before enabling it → The door opens to the right people. **Somebody joins and nobody assigns them permissions.** - Defines the default role → Whoever joins can work without waiting. **It is switched off and some users already came in that way.** - Reviews who came in through it → The change leaves no gaps. --- --- id: KB-ET-001 url: https://app.codecontract.io/help/your-workspace/setting-up-your-organisation idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: administrador actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-001, KB-ET-002, KB-ET-003, KB-ET-019] citadoPor: [KB-ET-002, KB-CC-001, KB-AD-001, KB-PS-003, KB-ET-004] enLaApp: https://app.codecontract.io/settings/organization --- # Setting up your organisation on day one _The four settings worth getting right before you send your first document._ **Responde a:** how do I change my organisation's name and logo · setting up the account for the first time · put my company logo on the emails that go out · what to do after creating the account You can start working without configuring anything, but four things are worth settling before your first send, because changing them afterwards does not fix what already went out: your contacts will have received a generic email under the wrong name. **En corto** - Your name and logo appear on everything your contacts receive. - Connecting your email makes notices come from your own domain and stay out of spam. - Badly configured internal alerts end up muted by the whole team. - Each contact's language decides what language they receive, not yours. ## 1. Name and logo It is the first thing the person you are asking for a document sees. A notice arriving with your company name and logo gets opened; a generic one looks like phishing and ends up in the bin. Change it in Settings → Organisation; it affects everything sent from that moment on. ## 2. Connect your email account Notices can go out from your own domain instead of a generic one. This is the single biggest improvement to deliverability: an email from your domain, with your authentication records in order, lands in the inbox. One without them lands in spam, and you conclude the supplier is not replying. > [!WARNING] > If notices still land in spam after connecting your email, an authentication record on your domain is almost always missing. That is for whoever runs your DNS, not for the platform. ## 3. Alerts The defaults notify fairly generously. It pays to turn them down at first and raise them later: a team receiving thirty platform emails a day ends up filtering all of them, including the ones that mattered. ## 4. Contact language Each contact carries their language on their record, and that is what is used when writing to them. Noting it when you add a foreign supplier saves the "I do not understand what you are asking for" conversation. ## Frequently asked questions **Can I change the logo later?** Yes, whenever you like. What does not change is what already went out: emails sent with the previous logo stay as they were. **Is connecting email mandatory?** No, it works without it. But response rates drop noticeably, because notices come from a domain your contacts do not recognise. **Can I have several organisations under one account?** Yes. One person can belong to several organisations and switch between them; each one's data is kept separate. **Who can change these settings?** The owner and administrators. An editor can work normally but cannot touch the organisation's configuration. ## Ejemplos **An accountancy starts using the platform and sends its first fifty requests without configuring anything.** - Notices half of them never reply - Checks that notices were going out from a generic domain - Connects their email and resends → The second batch gets three times the response rate, with the same text and the same people. **Everything is configured before there is a real case.** - Configures the minimum and adjusts with use → The configuration answers what actually happens. **The whole team is invited on day one.** - Whoever will use it that week comes in first → Nobody receives access to something empty. **Twenty folders are created before there are documents.** - Creates the structure as it is needed → The structure reflects the real work. **Nobody decides who administers.** - Names two administrators from the start → The account does not depend on one person. **The organisation's name and details are left half done.** - Completes them before sending anything out → What a third party receives is recognisable. --- --- id: KB-ET-002 url: https://app.codecontract.io/help/your-workspace/users-roles-and-permissions idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-001, KB-ET-003, KB-TL-003, KB-ET-021] citadoPor: [KB-ET-001, KB-ET-003, KB-AD-001, KB-GL-001, KB-AD-003, KB-ET-004, KB-ET-005] enLaApp: https://app.codecontract.io/settings/members --- # Users, roles and permissions _Who is a user, who is an external participant, and what each role can do._ **Responde a:** invite a colleague to the platform · difference between a user and an external participant · what permissions each role has · remove access for someone leaving the company · create user groups The most common confusion when starting out is thinking you have to create accounts for your suppliers. You do not: suppliers, clients and signers are external participants and have no account. Users are only people inside your organisation. **En corto** - User = someone in your company, with an account and a password. Uses a licence. - External participant = someone outside. Opens a link, has no account, uses no licence. - Four internal roles, most to least: owner, administrator, editor and reader. - Groups save assigning permissions person by person. **Who is who** — The four internal roles have accounts; external participants do not, and that is the distinction most often confused at the start. ## What each role can do | Role | Can | Cannot | | --- | --- | --- | | Owner | Everything, including billing and closing the account | — | | Administrator | Configure the organisation, invite and remove people, see everything | Touch billing | | Editor | Create processes, request documents, send for signature, certify | Change configuration or manage users | | Reader | View and download what they are assigned | Create or modify anything | _When in doubt, editor: that is the role of whoever does the day-to-day work._ ## Inviting someone 1. **Settings → Members → Invite** — Only their email is needed. They receive an invitation to set up their access. 2. **Pick the role** — It can be changed later, so there is no need to get it right first time. 3. **Add them to a group if you have several teams** — Groups are how someone sees their department's work rather than the whole company's. ## When someone leaves Removing access is immediate, but what they did does not vanish: the documents they uploaded, the processes they launched and the signatures they managed stay in place under their name. That is deliberate — if it disappeared, the history would stop being traceable. > [!WARNING] > Before removing access, check whether that person has running processes assigned to them. They can be reassigned; if you do not, they sit waiting for somebody who no longer logs in. ## Frequently asked questions **Does a supplier count as a user?** No. They are an external participant: they open a link, upload their part and have no account. No licence consumed. **Can I have someone who only views, without touching anything?** Yes, that is the reader role. **Do groups limit what is visible?** They organise access by team or department, so each one works with their own material. **Can there be more than one owner?** It is worth having at least two people able to administer, so you do not depend on a single account the day that person is away. ## Ejemplos **A 30-person company wants each department to see only its own work, while management sees everything.** - Creates one group per department - Gives editor to those doing the work and reader to those who only consult - Leaves management as administrators → Each team logs in and sees their own work without the rest of the noise, and management keeps the full picture. **Everyone has administrator rights.** - Gives each person what their job needs → Access stops being general by default. **Somebody cannot do something and is made an administrator.** - Checks which specific permission is needed → The minimum is granted. **Somebody changes role and keeps their permissions.** - Reviews permissions on role changes → Access follows the role. **Nobody knows who can see what.** - Checks permissions per person → The access picture exists. **An external party needs to see one file only.** - Grants access to that file and nothing else → They see theirs without reaching the rest. --- --- id: KB-ET-003 url: https://app.codecontract.io/help/your-workspace/your-contact-book idioma: en categoria: espacio-de-trabajo subcategoria: contactos audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-002, KB-TL-004, KB-PR-001] citadoPor: [KB-TL-010, KB-ET-018, KB-ET-020, KB-TL-027, KB-ET-001, KB-ET-002, KB-CC-001] enLaApp: https://app.codecontract.io/contacts --- # Your contact book, and why it decides whether people reply _A properly recorded contact is the difference between people delivering and you chasing._ **Responde a:** how do I add a contact · import contacts from a spreadsheet · contact groups for batch sending · why is a contact not receiving notices · change the language a supplier receives The contact book looks like the boring part and it is the one with the biggest effect on whether people reply. Most of the "nothing ever arrives" cases that reach support are an email with one letter wrong, or a landline where a mobile should be. **En corto** - Email and mobile: with both, if one fails you can chase on the other. - The contact's language decides what language they receive. - Groups let you request from or send for signature to fifty people at once. - A bounce is flagged on the case: you do not wait weeks to learn the address was wrong. ## What to record for each contact | Field | Why it matters | | --- | --- | | Name and company | It appears in the notice; without it, it reads as a mass mailing | | Email | The default channel | | Mobile | Essential for advanced signature and very useful for chasing on another channel | | Language | Decides what language the notice arrives in, with nothing for you to translate | | Preferred channel | Some people never read email but do read WhatsApp; respecting that raises replies | > [!WARNING] > A landline in the mobile field saves without complaint, but breaks advanced signature: the code goes by SMS and never arrives. It is the single biggest time-waster. ## Groups A group is a set of contacts you can request from or send for signature in one go: "raw material suppliers", "subcontractors on the Valencia site", "all staff". Each person gets their own link, not a shared send, so traceability stays individual. ## When something does not arrive 1. **Check whether the email bounced** — The case flags it. A bounce means a mistyped or non-existent address. 2. **Check whether the link was opened** — It separates "it never arrived" from "they have not looked", which are two different problems with two different fixes. 3. **Try another channel** — If you hold the mobile, resending by SMS or WhatsApp usually solves it immediately. ## Frequently asked questions **Can I import my contacts from a spreadsheet?** Yes. It is worth checking the mobile numbers first: that is the field that travels worst from a spreadsheet, especially with international prefixes. **Can one contact cover several people?** Each contact is one person. If two people handle you at a supplier, that is two contacts, so each receives their own. **What happens if I edit a contact with running processes?** Later sends use the new details. What was already sent stays as it was, with its record. **Can a contact be deleted?** Yes, but whatever took part in a case stays in the history: if it vanished, traceability would stop being traceability. ## Ejemplos **A company imports 200 contacts from a spreadsheet and a week later 15% have received nothing.** - Filters the bounces flagged on the cases - Fixes mistyped addresses and mobiles missing their country code - Resends only to those, without rebuilding the requests → Bounces drop to zero, and what was a data problem stops being blamed on "suppliers never reply". **The request goes to a generic mailbox and nobody replies.** - Records the specific person at each company → The request reaches somebody who can act. **The contact no longer works there.** - Updates the contact on the first bounce → Notices stop getting lost. **Each person keeps their contacts in their own inbox.** - Centralises the address book → Follow-up does not depend on who is in. **Contacts from the same company get duplicated.** - Reviews and merges the duplicates → The supplier receives one message, not three. **A contact does not read email but does read their phone.** - Records the channel they actually use → The notice arrives where it gets read. --- --- id: KB-ET-004 url: https://app.codecontract.io/help/your-workspace/organising-folders-and-projects idioma: en categoria: espacio-de-trabajo audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-001, KB-ET-002] citadoPor: [KB-ET-006, KB-PS-006, KB-ET-009, KB-ET-015, KB-CC-005] --- # Organising folders and projects _The structure that still works in two years, and the one that does not._ **Responde a:** how should i organise documents in folders · recommended folder structure · i cannot find documents · by project or by client Almost everyone starts organising by year and ends up finding nothing. The reason is simple: nobody looks for "the 2025 stuff", they look for "that supplier's stuff". **En corto** - Organise by what you get asked about, not by when it happened. - Three levels at most. Nobody uses the fourth. - If you hesitate about where something goes, the structure is wrong. ## What works | If you work by | Structure | | --- | --- | | Clients | Client → type of work → document | | Sites or projects | Site → subcontractor → document | | Internal areas | Area → process → document | _The first level is always whatever people name on the phone._ ## What does not work - By year: nobody asks about a year, and everything splits into arbitrary pieces. - By who uploaded it: that person leaves and the folder loses its meaning. - Five levels deep: things get filed wrong because nobody goes that far down. > [!NOTE] > The date is already on every document and can be filtered. It does not also need to be a folder. And even with a good structure, searching is usually faster than navigating: search looks inside documents, not just at their names. **Can I change the structure later?** Yes, folders move without losing anything. **Can a document live in two places?** Yes, it is linked rather than duplicated, and does not take up space twice. **Is a per-year folder inside each client worth it?** Only if you have a great deal per client. Otherwise it gets in the way. ## Ejemplos **An accountancy firm cannot find a client's documents from two years ago.** - Reorganises from year → client to client → type of work → Anyone on the team reaches a client's material in two clicks, without knowing which year it was. **A folder is created for every document.** - Uses folders to group and projects to work → The structure stops growing with every file. **Nobody finds anything because everyone organises their own way.** - Agrees a structure and applies it → Anyone reaches the same place. **Three jobs for the same client get mixed.** - Each job is a project → One can be closed without touching the others. **The whole structure is designed before being used.** - Starts with the minimum and grows with use → The structure answers the real work. **There are folders nobody has opened in a year.** - Reviews and archives what is unused → The structure stays readable. --- --- id: KB-ET-005 url: https://app.codecontract.io/help/your-workspace/what-permissions-to-give-each-person idioma: en categoria: espacio-de-trabajo subcategoria: usuarios audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-002, KB-AD-002, KB-ET-013] citadoPor: [KB-PR-007, KB-ET-008, KB-AD-005, KB-AD-006, KB-ET-010, KB-AD-008, KB-ET-016, KB-ET-021, KB-ET-007, KB-PS-005] enLaApp: https://app.codecontract.io/settings/members --- # What permissions to give each person _Neither everyone an administrator nor everyone read-only: the split that works._ **Responde a:** configure user permissions · what role should i give a colleague · limit what someone can do · team permissions Both extremes fail for the same reason: nobody stops to think who needs what. Everyone an administrator ends in an accidental deletion; everyone read-only ends with one person doing eight people's work. ## The split that usually works | Profile | Can | Cannot | | --- | --- | --- | | Administrator | Everything, including settings and permissions | — | | Manager | Create processes, launch sends, approve | Change organisation settings | | Contributor | Work on their own items, upload and respond | Delete, or touch other people's processes | | Read-only | View and download their own material | Change anything | ## Two practical rules - Two administrators, not one and not five. With one, if they lose access nobody can fix it; with five, nobody feels responsible. - Delete permission does the most damage and is needed least day to day. Grant it sparingly. > [!IMPORTANT] > An external adviser or accountancy firm does not need to administer your account. Give them read access to their own scope and nothing more: it is your information, not theirs. > [!NOTE] > Permissions get reviewed when someone changes role, not only when they join. A promotion leaves old permissions that no longer fit. > [!WARNING] > If you use teams, a broad permission in one team should not reach another team's documents. Check the scope, not just the level. **Can I give access to only one project?** Yes, scoped by team or by folder. **Can I see who did what?** Yes, every action carries its author. **Can a contributor invite others?** No, and it is better that way. ## Ejemplos **A twenty-person company has all twenty as administrators.** - Keeps two administrators - Four area managers - The rest as contributors within their team → Nobody loses the ability to work and the risk of someone deleting a whole case by accident disappears. **Broad permissions are granted so nobody is blocked.** - Grants what each role needs → The block clears without opening more than necessary. **An intern can see sensitive documentation.** - Reviews what belongs to each role → Sensitive material stays where it should. **Nobody has reviewed permissions in two years.** - Schedules a periodic review → Access reflects today's organisation. **An external party asks for access to the whole folder.** - Grants access to the file they need → They see theirs and nothing more. **Somebody leaves and their permissions stay active.** - Revokes access on their last day → The account reflects who works here. --- --- id: KB-ET-007 url: https://app.codecontract.io/help/your-workspace/working-with-several-companies-or-brands idioma: en categoria: espacio-de-trabajo subcategoria: cuenta audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-AD-003] citadoPor: [KB-ET-014] --- # Working with several companies _When one organisation with teams is right and when you need several._ **Responde a:** manage several legal entities in one account · separate subsidiaries or brands · one organisation or several · group of companies documentation The question comes up as soon as there is more than one entity, subsidiary or brand. The answer turns on one thing: whether the people and the documents overlap. | Situation | What suits | | --- | --- | | Several brands, same team, same suppliers | One organisation with teams | | Different entities sharing an admin function | One organisation with teams and scoped permissions | | Subsidiaries whose teams must not see each other | Separate organisations | | A firm managing its clients | One organisation, one team or folder per client | ## The practical rule Start with one organisation. Splitting later is easier than merging: moving documents between organisations is work, and splitting a history is what makes nothing add up afterwards. > [!IMPORTANT] > If two group entities compete or have different shareholders, separate them properly. A misconfigured permission between teams in one organisation is a configuration error; between separate organisations it cannot happen. ## What is shared and what is not - Within one organisation: contacts, templates, balance and settings. - Between organisations: nothing. They are independent accounts. > [!NOTE] > A person can belong to several organisations and switch between them without anything being mixed. **Can a case be moved from one to another?** It is manual work. Which is why it is worth deciding first. **Is the balance shared?** Within one organisation, yes. Between organisations, no. **What about invoicing separately?** It depends on your case; ask before building the structure. ## Ejemplos **A group with three entities and shared administration hesitates between one account or three.** - Sets up one organisation with a team per entity - Scopes each team's permissions → Administration works across all of them and each entity sees only its own, without triplicating templates and contacts. **Documents from two group companies get mixed.** - Separates each company into its own organisation → Each one holds its own. **One person works for two group companies.** - Grants access to both with a single account → No duplicate accounts or passwords. **A report mixes data from several companies.** - Queries by organisation → Each figure belongs to whom it should. **A client asks about the wrong company.** - Checks which organisation holds the file → You answer from the right one. **Something belonging to one company is shared from another.** - Shares from the owning organisation → The trail points at the right party. --- --- id: KB-TL-001 url: https://app.codecontract.io/help/trackline/requesting-documents-with-trackline idioma: en categoria: trackline subcategoria: empezar modulo: trackline audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-001, KB-PS-002, KB-TL-002, KB-TL-003] citadoPor: [KB-PS-001, KB-PS-002, KB-TL-002, KB-TL-003, KB-TL-004, KB-TL-005, KB-TL-006, KB-PR-001, KB-PR-002, KB-CS-001, KB-CS-002, KB-CR-001, KB-CR-002, KB-CR-003, KB-TL-014, KB-TL-019, KB-TL-028, KB-TL-015, KB-GL-011, KB-DI-001, KB-GL-001, KB-CF-002, KB-CF-006] enLaApp: https://app.codecontract.io/trackline/schemas --- # What Trackline is and how to request documents with it _Design the process once, run it as often as you like, and let the platform do the chasing._ **Responde a:** how do I request documents from a supplier · automate collecting supplier documentation · how do I stop chasing documents by email · what is Trackline · create a supplier onboarding process Trackline is for requesting documents and data from someone — a supplier, a client, an employee, your own team — without having to stand over them. You define what is needed, the platform asks for it, chases it if it does not arrive, reads what does arrive, and tells you when the case is complete. **En corto** - The "process" (what is always requested) is kept separate from each "case" (one specific run). - You design the process once; running it afterwards takes two clicks. - Whoever receives the request needs no account: they open a link and upload their part. - Reminders go out on their own and stop the moment the person delivers. - When a document arrives, automatic reading fills in the data and you confirm it. ## The idea: process and case are different things This is the only idea you need to grasp about Trackline, and everything else follows from it. On one side is the process — also called a schema: the template that says which documents are needed to onboard a supplier, for example. On the other is the case: what gets created every time you onboard one specific supplier. In email those two things are mixed together, which is why it is such hard work: every onboarding is written again from scratch. Here the process is designed once and run a hundred times. | What to look at | Process (schema) | Case | | --- | --- | --- | | What it is | The template of what gets asked for | One specific run of that template | | How many | One per type of procedure | One per supplier, client or matter | | How often you touch it | Designed once, tweaked occasionally | Created whenever you need one | | Example | "Supplier onboarding" | "Supplier onboarding — Gómez Workshops" | ## What you can ask for Not just files. Trackline distinguishes several request types, and picking the right one is what stops you having to chase the same person twice. | Type | What you ask for | When it fits | | --- | --- | --- | | Document | That they upload a file | A tax ID, a certificate, an invoice | | Data | That they fill in a form, uploading nothing | A bank account, a date, a size | | Document + data | That they upload the file and confirm some fields | "Upload the invoice and confirm the amount" | | Delivery | You are the one sending something to them | Sending the countersigned contract | | Approval | That they approve or reject, delivering nothing | Getting a manager to sign off | _If you need the file AND the figure, ask for both in one request: split them and the person gets two separate notices._ ## How to build a process, step by step 1. **Go to Trackline → Schemas → New schema** — Give it a name you will still recognise in six months. "Supplier onboarding" beats "Process 1". 2. **Create the first phase** — A phase is a block of things asked for at the same time. For example "Tax documentation". 3. **Add the requests inside it** — Each request is one thing you ask for: a document, some data, or both. Give it a clear title, because that is what the person outside will read. 4. **Say who each one goes to** — It can be someone outside (with their email or phone), someone on your team, or yourself if you are the one uploading it. 5. **Mark which ones are mandatory** — The case is not considered complete until every mandatory request is closed. The rest are nice to have but do not block. 6. **Add any further phases, and save** — There is no limit on phases. Once saved, the schema is ready to run as many times as you like. > [!NOTE] > If building it by hand feels like a chore: write what you need in plain language ("I want to ask my suppliers for their tax ID, their tax clearance certificate and their insurance") and the platform proposes the whole schema, phases and requests included. Then you edit it. ## What happens when you run it **A three-phase process** — Phases open in order: the second does not start until the first is complete. Within a phase, every request goes out at once. Running the schema creates a case and sends out the first phase's notices. Each person gets their own link — by email, SMS or WhatsApp, depending on what you hold for them — and uploads their part without registering anywhere. You can see at all times what has arrived and what has not. When a document arrives, automatic reading opens it, pulls out the data you asked for and fills it in. You review and confirm. Once every mandatory request in a phase is closed, the next phase opens by itself. > [!WARNING] > Automatic reading proposes, it does not decide. Every field comes with a confidence level and the final word is always yours: if something was read wrong, you correct it and the record shows that you were the one who corrected it. ## Common mistakes when starting out - Putting everything in one phase. Ask for twelve documents at once and the person freezes and sends none. Split them into sensible blocks. - Marking everything mandatory. If 80% genuinely is, the case ends up blocked by the 20% that never mattered. - Writing request titles for yourself instead of for the recipient. "Doc 3" means nothing to a supplier; "Tax clearance certificate" does. - Creating one schema per client. The schema is the template: one per client and you are back to email. ## Frequently asked questions **Can I change a case that is already running?** Yes. You can add requests, add participants and even add a whole new phase while the case is in progress. The changes affect that case, not the template. **If I change the schema, do existing cases change?** No. Each case keeps the version of the schema it was created with. Changing the template only affects cases you create from then on. **Can I reuse a similar schema without starting from scratch?** Yes: duplicate the one you have and edit the copy. It becomes an independent schema and the original is untouched. That is the usual move when you need a variant by sector or country. **Which channel does the notice reach the person on?** Whichever ones you have set up for them: email, SMS or WhatsApp. If you hold several, they can be notified on more than one. **What if the person has no email, only a phone?** It works the same. The link is sent by SMS or WhatsApp and they open it on their phone, where they can also photograph the document instead of uploading a file. ## Ejemplos **A construction company hires a subcontractor and cannot let them on site without up-to-date health and safety paperwork.** - Designs the "Subcontractor onboarding" schema with three phases: company, workers and machinery - Runs it when hiring, picking the site folder - Lets the platform chase whatever is missing until the case is complete → On the day of the inspection, that subcontractor's file is complete and every delivery is dated. **Every supplier onboarding is requested by hand over email.** - Designs the process once and launches it per supplier → The second onboarding takes two minutes instead of half an hour. **Nobody knows which suppliers have complete documentation.** - Checks the status of all of them at once → You act on the failing ones rather than all hundred. **Chasing the stragglers takes a morning a week.** - Lets the reminders go out on their own → The morning is recovered and the deliveries still arrive. **A client asks you to evidence what was requested and when.** - Checks the file's trail → The answer comes from the file itself. **Each person requests documents from their own list.** - Shares a single template → Everyone asks the same and the supplier gets a coherent message. --- --- id: KB-TL-002 url: https://app.codecontract.io/help/trackline/phases-putting-requests-in-order idioma: en categoria: trackline subcategoria: procesos modulo: trackline audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-003, KB-TL-004] citadoPor: [KB-TL-001, KB-TL-003, KB-TL-007, KB-TL-011, KB-TL-030] enLaApp: https://app.codecontract.io/trackline --- # Phases: putting what you ask for in order _When to split a process into phases, when not to, and what makes a phase open by itself._ **Responde a:** how do I order requests into phases · when to create a new phase in Trackline · why is the next phase not opening · staged document process A phase is a group of things asked for at the same time. They exist for one very specific reason: some requests make no sense until another has been resolved. You cannot ask someone to sign the contract before you know whether their paperwork checked out. **En corto** - Within a phase, everything goes out at once and is chased in parallel. - Between phases there is order: the next one does not open until the previous is complete. - "Complete" means every mandatory request is closed, not every request. - If two things can be asked for at the same time, they belong in the same phase. Splitting them only makes the process longer. ## When you actually need a new phase The practical rule is to ask: does what I am about to request depend on something I do not have yet? If yes, it belongs in a later phase. If no, it belongs in the same one. | Situation | New phase? | Why | | --- | --- | --- | | Asking for the tax ID and the social security certificate | No | They are independent: the person can send both together | | Reviewing the paperwork and then signing the contract | Yes | Nothing gets signed until the review has come back clean | | Asking the supplier for something, then having your team approve it | Yes | Your team cannot approve what has not arrived yet | | Asking three documents from three different people | No | They run in parallel; each moves at its own pace within the same phase | > [!WARNING] > Every extra phase is an extra wait. Split into five phases what could have been two and the case takes weeks longer to close even if nobody is late. ## What it means for a phase to be complete A phase counts as complete when every request marked mandatory is closed. The ones that are not mandatory can stay pending without blocking anything: they remain visible and can be delivered later. As soon as the phase completes, the next one opens by itself and its notices go out. Nothing to click — though you can also launch it manually if you want to get ahead. ## Changing phases mid-case You can. If halfway through an onboarding you discover you need a document nobody planned for, you add it to the current phase or create a new one, and that person gets the notice without starting over. The change affects only that case; the template stays as it was. ## Frequently asked questions **How many phases can a process have?** There is no technical limit. In practice, more than four or five usually means the model is too fine-grained and things should be merged. **Can I skip a phase?** You can launch the next one manually without waiting for the previous to close, if the situation calls for it. The record shows it was brought forward and by whom. **What if someone in phase 1 never delivers?** The case waits in that phase and you see it in the list of what is stuck. You can reassign the request to somebody else, make it non-mandatory, or cancel it. **Does everyone in a phase find out at the same time?** Yes. When the phase opens, all of its notices go out at once, each to its recipient on their own channel. ## Ejemplos **A law firm sets up a due diligence and wants the review not to start until all the corporate paperwork is in.** - Phase 1: deeds, powers of attorney and annual accounts, all at once to the client - Phase 2: risk report, assigned to the internal team - Phase 3: signing the agreement → The internal team gets no notice until phase 1 is complete, so nobody starts reviewing a half-finished file. **Twelve documents are requested at once and none arrives.** - Splits into phases and opens the essentials first → The first phase completes and the rest follows. **A phase depends on the previous one being approved.** - Sets it to open automatically when the previous closes → Nobody has to remember to open the next one. **The supplier receives requests they cannot yet meet.** - Orders phases by what actually depends on what → Each moment asks only for what is already possible. **A three-document process is split into phases.** - Leaves it as a single phase → Phases are used where they help rather than by habit. **A phase has been open for weeks and nobody notices.** - Reviews which phases have been open too long → The blockage surfaces without being hunted. --- --- id: KB-TL-003 url: https://app.codecontract.io/help/trackline/what-the-person-you-ask-actually-sees idioma: en categoria: trackline subcategoria: participantes modulo: trackline audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-002, KB-TL-004, KB-TL-020] citadoPor: [KB-TL-001, KB-TL-002, KB-TL-004, KB-TL-010, KB-TL-016, KB-CC-012, KB-TL-021, KB-TL-022, KB-PS-021, KB-PR-022, KB-CR-005, KB-ET-002, KB-DI-002] --- # What the person you ask actually sees _The other side of the process: what they receive, what they must do and why no account is needed._ **Responde a:** what does the supplier see when I request a document · does the supplier need an account to upload · how does an external person upload a document · link for a third party to upload documentation This is the part most worth understanding and the one almost nobody looks at, because it is invisible from your screen. When a supplier does not deliver, very often it is not unwillingness: it is that they did not understand what you were asking for, or did not know how to send it. **En corto** - They get a notice with their own personal link. - No sign-up, no password, nothing to install. - They see only their own part: not the rest of the case, not what others sent. - They can upload a file or photograph the document straight from their phone. ## What they receive A message — by email, SMS or WhatsApp — with your name, your organisation's name, what you need and a button. You can personalise the text: a message written by you gets noticeably more replies than a generic notice. > [!NOTE] > The notice goes out in that person's language, not yours, if you have recorded it on their contact card. ## What they do when they open the link 1. **They see the list of what you are asking for** — Only their own: their requests for this phase, with the title and description you wrote. 2. **They upload the file or take a photo** — From a phone they can photograph the document directly. If the photo comes out skewed, the platform straightens it. 3. **They fill in any data you asked for** — If the request included fields, they appear below the file, pre-filled with whatever could be read from the document. 4. **They confirm and finish** — They get an acknowledgement. If you asked for several things, they can come back later with the same link for whatever is left. ## Why they do not need an account That is a product decision, not a limitation. The person you are asking for a certificate is not your user: they are doing you an administrative favour. Forcing them to register means a share of them simply will not, and then you are back to chasing by email — exactly what you were trying to avoid. The link is personal: it identifies that person and that request, and gives access to nothing else. If they forward it to a colleague, the colleague can deliver on their behalf, and the record shows where it came from. ## Frequently asked questions **Can they see the rest of the case?** No. Each person sees only the requests assigned to them. They cannot see what other participants sent, nor the other phases. **Does the link expire?** It stays valid while the request is open. If you set a deadline on the process, it stops working once that passes. **What if they lose the email?** You resend the notice from the case in one click. It is the same link — nothing has to be rebuilt. **Can they deliver from a phone without an app?** Yes. There is no app to install: it opens in the phone's browser and they can photograph the document from there. **What if they upload the wrong document?** They can upload again with the same link. You see both versions and which one arrived first. ## Ejemplos **An accountancy asks thirty clients for paperwork, and half of them are sole traders who only use a phone.** - Sets up the notice on WhatsApp as well as email - Writes a personal message explaining what it is for and when it is needed - Lets each of them photograph the document from their phone → They deliver without ringing up to ask how it works, and the documents arrive readable because the platform straightens skewed photos. **A supplier spends half an hour looking for where to register.** - Explains they enter via the link with no account → They deliver the same day. **The supplier cannot tell which documents they already sent.** - Shows them what is missing and what is in → They send only what is missing. **The process is tested without seeing the supplier's side.** - Sends themselves the request and completes it → Design flaws surface before reaching anyone. **The supplier opens it from a phone on site.** - Uploads a photo of the document from that phone → Delivery happens where the document is. **A supplier with little digital confidence gets stuck.** - Phones them once and walks the link with them → The first delivery completes and later ones need no help. --- --- id: KB-TL-004 url: https://app.codecontract.io/help/trackline/what-to-do-when-someone-does-not-reply idioma: en categoria: trackline subcategoria: seguimiento modulo: trackline audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-003] citadoPor: [KB-TL-002, KB-TL-003, KB-TL-007, KB-TL-008, KB-CO-010, KB-CS-001, KB-PR-023, KB-PS-023, KB-TL-027, KB-ET-003, KB-CC-001, KB-CF-001] enLaApp: https://app.codecontract.io/insistencia --- # What to do when someone does not reply _Automatic reminders, switching channel, and when it is time to pick up the phone._ **Responde a:** the supplier is not replying what do I do · automatic reminders for document requests · how to chase without phoning · how often to send a reminder Chasing is the part of the job that eats the most time and that people enjoy least. Trackline automates it as far as it makes sense, and tells you when it no longer does. **En corto** - Reminders go out on their own, at whatever cadence you configure. - They can be sent on a different channel from the first notice. - They stop automatically as soon as the person delivers that specific request. - When the attempts run out, the alert comes to you instead of nagging on. **How chasing works** — Reminders are spaced out and can switch channel. As soon as the person delivers, they stop for that request without affecting the others. ## How to set it up When you create the process, or later on a specific case, you decide how often to remind and how many times. A sensible default is the first reminder after two or three days and the second after a week, on a different channel. > [!WARNING] > Reminding every day speeds nothing up: what it achieves is the person marking your messages as spam, and from then on they miss the important ones too. ## Switching channel This is what works best. If the first notice went by email and got no reply, a second one by SMS or WhatsApp lands somewhere else — usually a phone — and gets seen. The platform does it on its own if you have given it both contact details. ## When to step in by hand - When the reminders run out and there is still nothing: the platform tells you, and at that point it is a phone call. - When the person replies to the email instead of using the link: a sign they did not understand what to do. - When they deliver the wrong thing: better explained by you than by resending the same automated notice. - When the contact detail is wrong: if the email bounces or the number does not exist, no reminder is going to fix that. ## Frequently asked questions **Do reminders stop on their own once they deliver?** Yes, and only for that request. If you asked for three things and they delivered one, they keep getting reminders about the other two. **Can I send a reminder right now, without waiting?** Yes. There is a button on the case to resend the notice immediately, regardless of the automatic cadence. **How do I know the notice actually arrived?** The case shows when each notice was sent and on which channel. A bounced email is flagged, so a wrong contact detail surfaces without waiting weeks. **Can I mute reminders for one particular case?** Yes. They can be paused per case without touching the process configuration — which is what you want once you have already spoken to that person on the phone. ## Ejemplos **A company asks forty suppliers for their tax clearance certificate and after ten days twelve have replied.** - Lets the first automatic email reminder go out after three days - Sets the second one on WhatsApp after a week - Only calls the ones still silent after both → Out of forty possible calls you end up making five, and you make them knowing exactly what each person still owes. **The same email is resent by hand every week.** - Sets up the automatic reminder → Chasing stops consuming anybody's time. **The contact no longer works there.** - Changes the recipient in the file → The request reaches somebody who exists. **The email is not arriving and nobody knows.** - Checks the delivery status before insisting → The cause is tackled rather than the symptom. **After four reminders there is still no reply.** - Phones and records the call → The change of channel is recorded like everything else. **Somebody who already delivered another way is chased.** - Checks the file before chasing → An unfair chase is avoided. --- --- id: KB-TL-005 url: https://app.codecontract.io/help/trackline/duplicating-a-template idioma: en categoria: trackline subcategoria: plantillas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-006] citadoPor: [KB-TL-006, KB-TL-013, KB-TL-018, KB-CF-004] enLaApp: https://app.codecontract.io/trackline/schemas --- # Duplicating a template _Reuse a process that already works without touching the original._ **Responde a:** duplicate a process in trackline · copy an existing template · make a variant of a process · reuse a schema for another client When you need a process almost identical to one you already have — the same supplier onboarding but for another country, or another product family — there is no need to rebuild it: duplicate it and edit the copy. **En corto** - The copy is independent: editing it does not touch the original. - Running cases on the original are unaffected. - You can rename it, add phases and remove requests freely. ## How to do it 1. **Go to Trackline → Schemas.** 2. **On the schema's row, open the three-dot menu.** 3. **Click "Duplicate".** 4. **Rename the copy to something that tells it apart from the original.** ## When to duplicate and when not to | Situation | What to do | | --- | --- | | A variant by sector, country or product family | Duplicate and edit | | The process has changed for everyone | Edit the original, do not duplicate | | You want to try a change safely | Duplicate, test on the copy, then decide | | One client asks for something different | Add it to their running case, do not create a schema | _One schema per client is the sign something went wrong: the template is what repeats._ > [!WARNING] > Duplicating copies the structure, not the cases. Anything already running keeps the version it was created with. **Does the copy inherit changes to the original?** No. From the moment you duplicate, they are independent. **Can I duplicate a copy?** Yes, as many times as you like. **Are participants copied too?** The structure of who is asked for what is copied; the specific contacts are chosen when you run it. ## Ejemplos **A food business needs the same supplier onboarding but asking importers for a certificate of origin.** - Duplicates "Supplier onboarding" - Renames it to "Supplier onboarding — imports" - Adds the certificate of origin request → Two processes side by side, and the original keeps working for domestic suppliers. **The good template is edited for a one-off variant.** - Duplicates it and edits the copy → The original still serves the usual case. **There are four copies with the same name.** - Names each copy after the case it solves → Nobody launches from the wrong one. **An improvement is applied to only one copy.** - Decides which is the main one and updates the rest → Variants do not fall behind for good. **It is duplicated for a client who asks for one extra document.** - Adds only that document in the copy → The difference is visible at a glance. **Unused copies pile up.** - Archives those not launched in months → The template list stays readable. --- --- id: KB-TL-006 url: https://app.codecontract.io/help/trackline/mistakes-when-designing-a-template idioma: en categoria: trackline subcategoria: plantillas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-005] citadoPor: [KB-TL-005, KB-TL-011, KB-TL-018, KB-TL-015, KB-GL-012] enLaApp: https://app.codecontract.io/trackline/schemas --- # Five mistakes when designing a template _The mistakes that stop a well-thought-out process from working in practice._ **Responde a:** why are documents not being delivered · how to design a good trackline process · template best practices · the case gets stuck A process can be well thought out and still not work, and it is almost always one of these five things. All of them take five minutes to fix once spotted. **En corto** - Asking for everything at once means getting nothing. - Marking everything mandatory blocks the case on what never mattered. - Titles are read by someone outside, not by you. ## 1. Everything in one phase Twelve documents at once is overwhelming. The person opens the link, sees the list and leaves it for later. Splitting into sensible blocks — company, people, machinery — multiplies delivery. ## 2. Everything marked mandatory If 80% genuinely is, the case ends up blocked by the 20% that never mattered. Mandatory means it stops things, not that it would be nice to have. ## 3. Titles written for you "Doc 3" or "SS cert." mean nothing to a supplier. The request title is the first thing they read, and it decides whether they understand what you want. ## 4. One schema per client The template is what repeats. Create one per client and you are back to email, only with more steps. ## 5. Forgetting expiry A tax clearance certificate is valid for three months. With no expiry date, next year the case looks complete and is not. > [!NOTE] > If a process has been open for weeks, check these five before touching anything else: four times out of five it is here. **How many requests per phase is reasonable?** Three to six usually works. More than eight in one phase clearly reduces delivery. **Can I change this with the process running?** Yes, on the specific case. The template is fixed separately, for the ones that follow. ## Ejemplos **A subcontractor onboarding has been open three weeks with only two of eleven documents delivered.** - Splits the eleven across three phases - Leaves only the six that block site access as mandatory - Rewrites the titles with the document's full name → The next subcontractor delivers all six mandatory items in four days. **The template asks for documents nobody looks at.** - Reviews what is actually used and drops the rest → The supplier delivers sooner because less is asked. **Documents are named with internal acronyms.** - Uses names an outsider understands → Questions fall and correct deliveries rise. **Mandatory and optional are not distinguished.** - Marks each document accordingly → The supplier prioritises what actually blocks. **Nothing explains why each document is needed.** - Adds a line of context per document → People reply without a preceding call. **The paper circuit is copied with its dead steps.** - Removes steps that existed only because of paper → The new process is shorter than the one it replaces. --- --- id: KB-TL-007 url: https://app.codecontract.io/help/trackline/adding-to-a-running-case idioma: en categoria: trackline subcategoria: procesos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-002, KB-TL-004, KB-GL-018, KB-GL-019] citadoPor: [KB-TL-011] enLaApp: https://app.codecontract.io/trackline --- # Adding something to a running case _Request a document you had not planned for without rebuilding anything._ **Responde a:** add a document to a running process · ask a supplier for something extra · add a participant to an open case · modify a process already launched Halfway through an onboarding you discover something is missing: a certificate nobody planned for, a new person from the subcontractor, a whole phase that did not exist. There is no need to cancel and start again. **En corto** - You can add a request, a participant or a phase with the case open. - The notice reaches only whoever it affects, not everyone. - The change belongs to that case: the template is untouched. ## What you can add | You add | Who finds out | When the notice goes | | --- | --- | --- | | A request to someone already involved | Only that person | Immediately | | A new participant | Only the new one | Immediately | | A whole phase | The people in that phase | When the phase opens | > [!WARNING] > If you add something mandatory to a case that was about to close, it becomes incomplete again. That is correct, but worth knowing before you click. ## What does NOT change - The original template, unchanged for future cases. - Anything already delivered, which keeps its date. - Notices that already went out. **Can I remove a request instead of adding one?** Yes, or mark it non-mandatory if it no longer blocks. **What if the person had already finished?** They get a new notice about what is missing, using the same link as before. **Is it recorded that it was added later?** Yes, with the date and who did it. ## Ejemplos **Halfway through a subcontractor onboarding, two new workers join the site.** - Adds both as participants on the open case - Each receives their own health and safety request → They start on site with a complete file without redoing the company onboarding. **A client adds a requirement with the file half done.** - Adds the document to the file in flight → Nothing is rebuilt and nothing already delivered is re-requested. **A document nobody foresaw turns out to be missing.** - Adds it and gives notice only of that addition → The supplier clearly sees what is new. **It is added to the template expecting open files to change.** - Also adds it to the in-flight files that need it → What is open reflects the new requirement. **A document is added to fifty files by hand.** - Adds it in bulk to the relevant ones → The change applies in minutes. **Something is added and the supplier is unaware.** - Checks the notice for the addition goes out → The addition does not sit waiting in silence. --- --- id: KB-TL-008 url: https://app.codecontract.io/help/trackline/seeing-which-cases-are-stuck idioma: en categoria: trackline subcategoria: seguimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-004, KB-CR-007] citadoPor: [KB-TL-009, KB-TL-012, KB-TD-001, KB-TL-017, KB-PS-022, KB-CF-005, KB-MA-002] enLaApp: https://app.codecontract.io/trackline --- # Seeing which cases are stuck _The view worth checking once a week, and what to do with what it shows._ **Responde a:** see the status of my processes · which cases have been open longest · filter incomplete cases · who has not delivered yet Having twenty open cases says nothing: it might be a normal week. What does say something is how many have been waiting more than two weeks on the same person. **En corto** - Filter by age, not by count. - Separate those who never opened the notice from those who opened and did not deliver. - Anything stuck on a wrong contact detail will not be fixed by chasing. ## The three states that matter | What you see | What it means | What to do | | --- | --- | --- | | The link was never opened | Either it did not arrive, or it is in spam | Check the contact and resend on another channel | | Opened and not delivered | They did not understand, or do not have it to hand | A personal message usually unblocks it | | Partially delivered | Some mandatory items are missing | Remind only about what is left | > [!NOTE] > Half an hour on Mondays filtering by age avoids nearly every case that ends up dead: what has been stuck a month rarely restarts on its own. **Can I see only mine?** Yes, by filtering on owner. **Can the list be exported?** Yes, with its dates, which is what a meeting needs. **What about ones that will never close?** Better cancelled than left open: a list full of dead cases stops being looked at. ## Ejemplos **A manager reviews on Mondays and finds four cases older than three weeks.** - Two never opened the notice: fixes the email and resends by WhatsApp - One opened it and did not understand: sends two lines - Cancels the fourth because that supplier no longer works with them → Three close that week and the list becomes worth looking at again. **All twenty files are reviewed one by one every Monday.** - Filters by those with no movement for a while → The review goes from half an hour to two minutes. **A file has been stalled a month and nobody had seen it.** - Checks the stalled view once a week → The blockage is caught in days rather than months. **A long list comes out and nobody knows where to start.** - Sorts by how long they have been stalled → The oldest is tackled first. **Stalled files are waiting on somebody internal.** - Separates what waits inside from what waits outside → Each list has a different action. **The review closes without acting on anything.** - Decides per file: chase, change channel or close → The weekly review produces decisions. --- --- id: KB-TL-009 url: https://app.codecontract.io/help/trackline/downloading-a-whole-case idioma: en categoria: trackline subcategoria: seguimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-008, KB-TZ-001] citadoPor: [KB-IC-001, KB-CF-003] enLaApp: https://app.codecontract.io/trackline --- # Downloading a whole case _Take everything from one supplier or matter at once, with its dates._ **Responde a:** download every document in a case · export a complete process · send all the documentation to a third party · export the data to a spreadsheet The moment to hand things over arrives: an inspection, a client asking for the file, a change of advisers. Downloading documents one by one is half a morning; the whole case downloads in one go. **En corto** - Documents come down with their phase structure. - Extracted data comes separately, so it opens in a spreadsheet. - Dates travel with the download: without them it would prove nothing. ## What you get - Every delivered document, organised by phase. - The data extracted from each one. - Who delivered what, and when. > [!WARNING] > If you are sending it to someone outside, check first for documents with personal data that did not need sharing. The download takes everything. ## When to use the link instead If whoever asked only needs to look at it, a link is better: it is checked on the spot, takes no space and leaves no copy in anyone's inbox. Downloading is for when the file itself has to change hands. **Does the data come in a spreadsheet-friendly format?** Yes, so you can filter it and cross it with your own. **Can I download only one phase?** Yes, or only the documents you select. **Is my download recorded?** Yes, accesses and downloads are part of the traceability. ## Ejemplos **A client changes advisers and asks for their whole file from the last three years.** - Downloads that client's cases - Checks no third-party documents are inside → It is handed over in one go, with every document's date, and without spending a morning on it. **A client asks for everything on a supplier and it is sent document by document.** - Downloads the complete file at once → The handover is prepared in a minute. **The file with its dates is needed for an audit.** - Downloads including the trail → You hand over what backs it, not only the files. **It is downloaded and then nobody knows what each file is.** - Checks the names reflect the document → Whoever receives it finds their way without explanation. **Only part of the file is needed.** - Selects what is relevant before downloading → What was asked for is delivered, and nothing more. **The download is saved on one person's machine.** - Shares from the platform instead of downloading → There is a trail of who saw it. --- --- id: KB-TL-010 url: https://app.codecontract.io/help/trackline/resending-a-link-to-a-participant idioma: en categoria: trackline subcategoria: participantes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-003, KB-ET-003, KB-TL-024, KB-TL-027] citadoPor: [KB-TL-020] --- # Resending someone's link _What to do when they say nothing arrived, in the order that works._ **Responde a:** the supplier says the link never arrived · resend the document request · the participant's email bounces · change a participant's email "Nothing arrived" is the most repeated sentence, and it almost never means the same thing. Before resending it pays to look at what happened, because resending to a wrong address fixes nothing. **En corto** - The case flags whether the email bounced and whether the link was opened. - A bounce means a wrong detail: resending without fixing it is pointless. - The link is always the same; resending does not invalidate the previous one. ## The order that saves time 1. **Check whether it bounced** — If it bounced, the address is wrong. Fix it on the contact record first. 2. **Check whether it was opened** — If it was opened, it arrived. The problem is something else: they did not understand, or do not have it to hand. 3. **Resend, preferably on another channel** — If you hold their mobile, SMS or WhatsApp lands somewhere else and gets seen. > [!NOTE] > If they reply to the email instead of using the link, it did arrive: they did not realise they had to click. A personal message sorts it. **Does the old link stop working when I resend?** No, it is the same one. If they saved the email, it still works. **Can I send it to someone else at the same company?** Yes, by adding them as a participant. Forwarding another person's link also works, but the record shows where it was delivered from. **How many times can I resend?** As many as you like, though past the third it is worth phoning. ## Ejemplos **A supplier insists nothing has arrived and it has been two weeks.** - Checks the case: the email bounced on day one - Fixes the address, which had an extra letter - Resends and pings them on WhatsApp → They deliver that afternoon, after two weeks wrongly blamed on "not replying". **The recipient says it never arrived.** - Checks the address and send status first → The cause is fixed before resending. **The link was sent to a shared mailbox.** - Resends it to the specific person → The delivery stands in the name of whoever makes it. **It is resent many times and several links are circulating.** - Resends from the file rather than forwarding the email → Only one valid link is in circulation. **The right recipient is somebody else.** - Changes the contact before resending → Future reminders already go to the right place. **The recipient's email bounces.** - Confirms the address by phone → The resend reaches a mailbox that exists. --- --- id: KB-TL-011 url: https://app.codecontract.io/help/trackline/approving-or-rejecting-what-is-delivered idioma: en categoria: trackline subcategoria: procesos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-002, KB-TL-006, KB-TL-007] citadoPor: [KB-CF-009, KB-TL-016] enLaApp: https://app.codecontract.io/trackline --- # Approving or rejecting what is delivered _Delivered does not mean acceptable. How to review without stalling everything._ **Responde a:** review documents a supplier delivers · reject a document and request another · approve received documentation · the delivered document is not valid A supplier uploads an expired certificate, or the policy of another company in the group, or a screenshot instead of the document. Delivered, yes; valid, no. Approval is what separates the two. **En corto** - Rejecting states what is wrong and re-requests it, in one step. - The case is not treated as complete with a rejected item inside. - Whoever approves need not be whoever asked. ## How to reject well 1. **Say what is wrong, specifically** — "It expired in March" or "it is a different company" gets fixed first time. "Not valid" generates three emails. 2. **Keep the original** — It is not deleted: it stays as an attempt, with its date. That is what shows it was asked for in time. 3. **The request reopens itself** — The third party gets a notice with your reason and the same link as always. | What usually goes wrong | What to write when rejecting | | --- | --- | | Expired certificate | "Expired 12/03; a current one is needed" | | Wrong legal entity | "This is the parent company; we need the invoicing entity" | | Illegible photo | "The number is unreadable; a scan is needed" | | Incomplete document | "Pages 3 and 4 are missing" | > [!WARNING] > Reviewing everything by hand does not scale. Keep manual approval for what genuinely needs it — insurance, qualifications — and let the rest be accepted on delivery. > [!NOTE] > If you reject the same document type from many people, the problem is how you ask for it. Change the request title before continuing to reject. **Does the person who delivered find out?** Yes, with the reason you write. **Can I approve with reservations?** You can approve and leave a note; the case moves on and the note stays. **Who can approve?** Whoever holds that permission. It is often better that it is not the person who asked. ## Ejemplos **Four suppliers send the parent company's insurance instead of the invoicing entity's.** - Rejects them stating exactly that - Changes the request title to "Insurance for the entity that issues the invoices" → All four correct it first time and it stops happening with later suppliers. **Everything that arrives is approved without looking.** - Checks at least validity and that it is the requested document → A complete file means something. **It is rejected without explaining why.** - States exactly what is missing → The second attempt arrives right. **Reviews pile up and hold everything back.** - Shares reviewing among those who can do it → The bottleneck stops being one person. **An expired document is approved unnoticed.** - Checks the date before approving → The expiry warning stays true. **Nobody knows what is awaiting review.** - Checks the list of deliveries pending review → Reviewing stops depending on remembering. --- --- id: KB-TL-012 url: https://app.codecontract.io/help/trackline/closing-a-case-that-is-going-nowhere idioma: en categoria: trackline subcategoria: seguimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-008, KB-CF-005, KB-TL-017] citadoPor: [KB-TD-017] enLaApp: https://app.codecontract.io/trackline --- # Closing a case that is going nowhere _When to stop chasing, how to close it, and why leaving it open is worse._ **Responde a:** cancel a case · the supplier is never going to deliver · close an incomplete process · clean up old processes Some cases will never close: the supplier no longer works with you, the project fell through, the person changed jobs. Leaving them open just in case has a concrete cost: the list fills with noise and stops being looked at. **En corto** - A list half full of dead cases stops being useful at all. - Closing does not delete: what was delivered stays, with the reason. - Closing with a reason beats letting it rot. ## When to close | Situation | What to do | | --- | --- | | The supplier no longer works with you | Close as not applicable | | The project was cancelled | Close stating the reason | | Three months stalled with no reply | One last attempt by phone; failing that, close | | Something is missing you know they will never provide | Decide whether it really blocks; if not, unmark it and close | > [!IMPORTANT] > Closing an incomplete case is a decision, and it is recorded as one with its reason. That beats leaving it open: a year from now, "closed because the supplier ceased trading" makes sense; an open, dead case does not. ## What is kept Everything delivered stays, with its dates. Closing is not deleting; it is ceasing to wait. > [!NOTE] > Reviewing quarterly whatever has been stalled over two months, and closing what is going nowhere, keeps the list at a size someone will actually look at. **Can it be reopened?** Yes, if the supplier reappears. **Is the third party notified?** You can, and it is usually right to if something had been asked of them. **Does it count as a breach in a report?** Closed-with-reason is distinguished from simply incomplete. ## Ejemplos **A list holds 140 open cases and nobody looks at it any more.** - Filters those stalled over two months - Closes 60 with their reasons - Phones the 12 that are genuinely live → 68 real cases remain and the list becomes a working tool again. **A file has been open for months without moving.** - Closes it, stating the reason → The open list becomes true again. **It is left open in case the supplier comes back.** - Closes it and reopens if they return → The metrics stop being contaminated. **It is closed with no record of why.** - Notes the reason for closing → Months later the decision can be explained. **The supplier comes back after it was closed.** - Reopens the file with its history → Nothing already delivered is lost. **Nobody knows when to stop chasing.** - Sets a closing criterion by reminders or elapsed time → The decision stops being taken case by case. --- --- id: KB-TL-013 url: https://app.codecontract.io/help/trackline/launching-one-process-for-many-at-once idioma: en categoria: trackline subcategoria: procesos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-004, KB-TL-005] citadoPor: [KB-CO-014, KB-CF-010] enLaApp: https://app.codecontract.io/trackline --- # Launching one process for many _The annual review of two hundred suppliers as a single operation._ **Responde a:** request documentation from all suppliers at once · annual supplier review · launch processes in bulk · refresh documentation across the whole base Once a year you have to ask everyone for the same thing: renewed insurance, current certificates, updated details. One by one that is two weeks; in bulk it is an afternoon and some follow-up. **En corto** - One process, one list, one launch. - Each person receives their own, with their name, not a group email. - Tracking covers the whole batch and tells you who to phone. ## How to prepare it 1. **Choose who** — Filter: the active ones, one sector, those expiring this quarter. It need not be everyone. 2. **Choose the process** — The same for all. If some need something different, that is two batches, not one with exceptions. 3. **Test on five** — Before the two hundred. That is where a badly worded title shows up. 4. **Launch and leave it a week** — Reminders go out on their own; you look on day seven. ## What responds and when | Point | What to expect | | --- | --- | | First 48 hours | Those who have it to hand | | After the first reminder | The bulk | | After the second | The stragglers | | Beyond that | Phone; email adds nothing more | > [!WARNING] > Launching to two hundred with the process built wrong is two hundred conversations. Testing on five costs a day and is the difference between a campaign and an incident. > [!NOTE] > Running the annual review on a fixed date — always January, always September — means third parties expect it, and that raises delivery more than any reminder. **Can I exclude someone from the batch?** Yes, when choosing the list. **What about someone who delivered a month ago?** Filter them out: asking for what they just sent burns goodwill. **Can it be stopped halfway?** Yes. What launched continues; the rest does not go. ## Ejemplos **A company reviews 210 suppliers' documentation every January.** - Tests on five on 7 January - Launches all 210 on the 8th - Phones the outstanding ones on the 20th → 85% deliver on their own before month end; the real work is thirty calls, not two hundred. **The annual review is done supplier by supplier.** - Launches the same process to all at once → The campaign is prepared in an afternoon. **Launching in bulk brings a hundred identical questions.** - Includes the context in the notice itself → Query volume drops from the first send. **Some suppliers are already fully current.** - Excludes those with nothing to provide → Nobody who already complied is bothered. **Nobody knows how the campaign is going.** - Checks progress per supplier → Follow-up is a screen rather than a spreadsheet. **It launches in August and nobody replies.** - Picks the date against the sector's calendar → Response rates rise without changing anything else. --- --- id: KB-TL-014 url: https://app.codecontract.io/help/trackline/your-first-process-in-half-an-hour idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-GL-011, KB-TL-030] citadoPor: [KB-PS-010, KB-TL-019] enLaApp: https://app.codecontract.io/trackline --- # Your first process, in half an hour _Ask a real person for paperwork and watch the whole circuit work._ **Responde a:** how do i start with trackline · create my first process · request documents for the first time · trackline getting started The fastest way to understand Trackline is not reading documentation: it is running one real case end to end, even if that first time takes longer than sending an email. After that, everything else explains itself. ## Pick a real case Something on your desk today: a supplier to chase for insurance, a subcontractor starting next week. An invented case teaches nothing, because it forces no decisions. ## The four steps 1. **Create the process** — Name it what it is: "Supplier onboarding", not "Test 1". 2. **Write what you are asking for** — Three or four things, with each document's full name. Mark mandatory only what genuinely blocks. 3. **Add the person** — Their name, email, and mobile if you have it. 4. **Launch it** — They receive a link. No account, no password. ## What you will see afterwards - Whether the notice arrived and whether they opened it. - What they have delivered and what is missing. - When each item arrived, with its date. > [!NOTE] > Send yourself the link before launching for real. It takes a minute and shows you how your request looks from outside — usually worse than it seemed while writing it. > [!WARNING] > Do not build twelve processes on day one. One that works teaches more than twelve half-built, and you will build the second better precisely because you built the first. > [!IMPORTANT] > When this case closes, save it as a template. That is what turns the second supplier into two minutes of work, and it is the entire reason this exists. **How long does it really take?** Half an hour the first time. Two minutes from the second onward. **What if I word the request badly?** It is corrected with the case running, without rebuilding anything. **Does the supplier have to install anything?** No. They open a link and upload their files. ## Ejemplos **Someone wants to try the platform and does not know where to start.** - Takes the supplier they were about to email that morning - Builds the process with its four documents - Sends themselves the link before launching → The supplier delivers in two days and the process is saved for the next twenty. **The first half hour goes on browsing options.** - Launches a real request to someone you trust → You come out having seen the whole circuit. **A complicated case is chosen for the first trial.** - Requests two documents and nothing else → The first attempt completes. **Nobody knows what it looks like from outside.** - Sends the request to themselves → You see the supplier's side before anyone else does. **The perfect template is built before testing.** - Launches with what exists and corrects afterwards → Corrections come from real use. **It is tested and nothing learned is kept.** - Saves the corrected process as a template → The second time takes two minutes. --- --- id: KB-TL-016 url: https://app.codecontract.io/help/trackline/a-file-with-many-participants idioma: en categoria: trackline subcategoria: participantes audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-003, KB-TL-011] citadoPor: [KB-TL-020] --- # A file with many participants _When eight companies take part in the same process and nobody knows whose turn it is._ **Responde a:** process with several suppliers at once · who must supply what in a file · file with many parties · coordinating several companies in one process A simple file has two sides: you and someone. The troublesome ones have eight: the supplier, their subcontractor, the engineer who certifies, the client who approves, the insurer. And the jam is rarely about documents: it is about knowing whose turn it is. ## The three roles worth distinguishing | Role | What they do | What they need to see | | --- | --- | --- | | The contributor | Uploads their part | Only what is asked of them | | The reviewer or approver | Signs off | What was supplied and the criteria | | The observer | Follows the status | Progress, not files | > [!IMPORTANT] > Mixing the first and third is the usual mistake: contributor access is granted to someone who only wanted to be kept informed, and documents appear uploaded by people who should not have, in the wrong place. ## How to avoid the jam 1. **Every requested item has a single owner** — If two people can supply it, neither does. 2. **Phases reflect the real order** — If the engineer cannot certify until the supplier uploads, the system should say so. 3. **Chasing goes to whoever is up** — Reminding everyone when one is missing is the fastest way to make people stop reading alerts. 4. **And it is obvious at a glance who is blocking** — It is the only question everyone asks in a file like this. > [!WARNING] > Beware long chains. When the person who must supply depends in turn on someone who is not in the file (the subcontractor's subcontractor), the process stalls at a point you cannot see. If that happens twice, that third party needs to become a participant. ## When someone changes midway **En corto** - Replace the participant, do not open another file. - What was supplied stays: it belongs to the file, not the person. - And the newcomer receives what is missing, not everything from scratch. > [!NOTE] > Each external participant enters by their link and sees only their part, with no account in your organisation. That is what makes eight parties possible without eight users to administer. **Can they see each other?** Only if you decide so. By default each sees their own. **What if two supply the same document?** Keep one and clarify who maintains it; better avoided by assigning a single owner. **Can approval happen in parts?** Yes, and in long files it is what stops everything waiting on the last item. ## Ejemplos **A commissioning file involves six companies and has been stuck for three weeks.** - Assigns a single owner to each requested document - Orders the phases by real dependency → It emerges the block was a certificate depending on an uninvited third party, resolved in two days. **Eight companies take part and nobody knows whose turn it is.** - Assigns each document to its participant → Each one sees only their part. **A participant can see another company's documents.** - Reviews the scope of each link → Confidentiality does not rest on nobody looking. **Everyone is chased when one is missing.** - Chases only whoever has something outstanding → Those who complied receive no reminders. **Two participants upload the same document.** - Makes clear who provides what → Duplicated work is avoided. **You want to know who is behind.** - Checks progress per participant → The conversation happens with the right party. --- --- id: KB-TL-017 url: https://app.codecontract.io/help/trackline/how-long-a-file-takes-to-close idioma: en categoria: trackline subcategoria: seguimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-008, KB-IC-006] citadoPor: [KB-TL-012] --- # How long a file takes to close _The figure that warns earlier than any other, and how to read it without fooling yourself._ **Responde a:** how long we take to complete a process · measuring file cycle time · why closing takes so long · processing time indicator The percentage of files up to date is the figure everyone watches, and it warns worst: it holds up nicely until it suddenly drops. Average time to close moves weeks earlier, because it picks up what is jamming right now. ## The three ways to read it | Measure | What it says | When it misleads | | --- | --- | --- | | Mean | General behaviour | Four endless cases inflate it and everything looks bad | | Median | How the typical case goes | It hides a tail of very old cases | | Oldest still open | Where the specific problem is | It never misleads, and it is the least watched | > [!IMPORTANT] > Look at all three, especially the third. If the mean worsens but the median does not move, you do not have a process problem: you have four specific jammed cases, and that is fixed with four conversations, not a redesign. ## Where the time actually goes 1. **Waiting for someone outside to supply** — Almost always the longest leg, and the one automatic chasing shortens most. 2. **Waiting for someone inside to review** — The second, and the most uncomfortable to admit. 3. **In a step nobody knows is theirs** — The classic in multi-party processes. 4. **And in formal closure** — Files finished in practice that nobody marks as closed. > [!WARNING] > The fourth pollutes every figure and is not a real problem: closing them when they finish already delivers half the apparent improvement. Rule it out before drawing conclusions about the process. ## What to do with the figure **En corto** - Compare it with itself, month to month, not with anyone outside. - Split it by file type: an onboarding does not take as long as a renewal. - And look at the leg, not the total: the total does not say where to act. Once split by legs, the conversation changes: it stops being "we're slow" and becomes "eleven days waiting for the supplier and four to review", which are two different problems with two different owners. > [!NOTE] > If time falls but approved exceptions rise, you have not improved: you have started letting things through. The two figures are read together or not at all. **How often should it be checked?** Monthly. Weekly only while correcting something. **What if we have few files?** Look at the oldest one open; a mean over few cases says nothing. **Is it useful for targets?** Yes, but per leg. A target on the total is met by whoever closes early, not whoever works better. ## Ejemplos **A team sees its average time rise and considers redesigning the process.** - Checks the median, which has not moved, and the oldest open file - Resolves four jammed cases → The average returns to normal without touching the process, which was not the problem. **Average time rises and nobody knows why.** - Checks whether the rise comes from one phase → The stretch that lengthened is tackled. **The average hides a few very long cases.** - Also looks at the extremes → You see the real problem rather than the mean. **The figure is compared across months without context.** - Accounts for campaigns and holidays → The comparison is honest. **Time is counted from when someone opens it by hand.** - Counts from when the request was sent → The figure reflects what the other side waits. **It is measured and nothing is done with the figure.** - Sets a target and reviews monthly → The indicator supports a decision. --- --- id: KB-TL-018 url: https://app.codecontract.io/help/trackline/one-template-for-everyone-or-one-per-client idioma: en categoria: trackline subcategoria: plantillas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-005, KB-TL-006, KB-TL-015] citadoPor: [KB-GL-019, KB-TL-030] --- # One template for everyone or one per client? _The decision that determines whether in a year you have three templates or forty._ **Responde a:** how many process templates do i need · a different template per client · maintaining many templates · simplifying the processes we have At first you build one template. Then a client asks for something different and it gets duplicated "just for them". A year later there are forty near-identical templates, nobody knows which to use, and changing one thing means editing forty. ## The rule that prevents proliferation > [!IMPORTANT] > **Duplicate a template only when the steps change, not when what is requested within a step changes.** If the process is the same and only the document list varies, you do not need two templates. ## When another really is needed | Situation | New template? | Why | | --- | --- | --- | | The phase order is different | Yes | It is another process, however similar | | There is an approval step the other lacks | Yes | Who takes part changes | | Two extra documents are requested | No | Same sequence, different content | | It is for another country with different names | It depends | If only the wording changes, no | ## How to tell there are too many **En corto** - Someone asks which to use and the answer starts with "it depends on…". - Two have nearly identical names and nobody recalls the difference. - A regulatory change forces editing more than five. - And some templates have not been used in six months. > [!WARNING] > The fourth is the easiest to fix and the least examined: a template unused for six months should be retired or marked. Leaving it guarantees someone uses it by mistake exactly when it matters. ## The clean-up, once it has happened 1. **List them by actual use** — How many files were launched with each in the last year. 2. **Group those sharing a sequence** — Usually three or four families emerge, not forty unique cases. 3. **Keep one per family** — With the variation inside, not as a separate template. 4. **And retire what is unused, without deleting files** — Files launched with it still exist; what is retired is the template. > [!NOTE] > Having AI draft a process helps you start, but it does not replace this decision: it can generate forty correct templates as fast as three, and writing them was never the problem. **What if a client demands their own circuit?** Then it genuinely is another process: who takes part and in what order changes. **Can I change a template with files in progress?** Yes, and those already launched carry on with the version they started with. **How many is reasonable?** Fewer than you have, almost always. One per process family. ## Ejemplos **A company has accumulated thirty-one supplier onboarding templates.** - Groups them by sequence and finds three families - Keeps three templates with the variation inside → A regulatory change is applied by editing three templates instead of thirty-one. **A template is created per client and there are already twenty.** - Unifies into one and marks the specifics as optional → Improvements reach everyone at once. **One client demands a document no other asks for.** - Creates a variant for that case alone → The exception does not contaminate the general template. **Nobody knows which template fits a new client.** - Names templates by case type → The choice is obvious. **An improvement reaches three templates and not the others.** - Reduces the number of templates before improving → Maintenance stops multiplying. **A copy is made for a one-line change.** - Uses an optional field instead of a copy → The template list does not grow with every nuance. --- --- id: KB-TL-019 url: https://app.codecontract.io/help/trackline/when-you-do-not-need-a-process idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-014, KB-TL-028] citadoPor: [KB-SC-018, KB-TL-028] --- # When you do not need a process _Turning everything into a process is the second-month mistake. Some requests are settled with a message._ **Responde a:** when to use a process and when not · setting up a process for a single document · this is too much for what I need · asking for something one-off When something works, the temptation is to use it for everything. A month in, single-step processes start appearing, with one person and one document — which is exactly a well-written message's job, with three configuration screens in front of it. ## What fits where | Situation | A message is enough | Worth a process | | --- | --- | --- | | One document, one person, once | Yes | — | | The same thing to several people at once | — | Yes: the follow-up runs itself | | Something that will repeat every year | — | Yes, even if today it is one | | Several items to review and approve | — | Yes, that is where the difference lies | | An urgent favour from someone you trust | Yes | — | > [!IMPORTANT] > The distinction that orders all this is not size: **it is whether someone will have to chase it**. A document that either arrives today or does not needs no structure. One that has to be chased three times, that expires, that someone else must approve or that you will be asked for again next year does — and building it then costs the same as building it now, except that now you have not chased anybody yet. ## What you lose by doing too little **En corto** - The trail: who asked for what, when, and what they answered. - The reminders, which is what prevents next week's phone calls. - And being able to repeat it without thinking it through again. > [!WARNING] > And what you lose by doing too much, which gets flagged less often: **a single-step process asks the other side to go somewhere to hand over one thing**. For an outsider that is more friction than replying to an email, and friction is paid for in answers that never arrive. If the goal is for them to send something today, what matters is that it is easy for the sender, not comfortable for the filer. ## The rule that works in practice 1. **One-off and nothing to chase: message** — And filed in the right place on arrival. 2. **Repeats, expires or needs approval: process** — Even if today it affects one person only. 3. **And if it started as a message and you are on the third chase** — That was already a process: convert it before the fourth. > [!NOTE] > Turning a one-off into a process later is not starting over: what you already received gets folded in. What cannot be recovered is the trail of the times you chased it outside the system. **What if I do not know whether it will repeat?** Start simple. The third time will tell you. **Is a one-step process a mistake?** Not if it buys a trail and reminders. Yes, if it only adds clicks. **Can I ask by email and still file it?** Yes, but filing by hand depends on someone remembering. ## Ejemplos **A company builds a full process to ask a trusted client for a one-off certificate.** - Asks by message and builds the process for the annual renewal, which does repeat → The document arrives the same day and the repeating part is set up where it matters. **A process is built to request one document from a colleague.** - Asks them by message and they upload it → Processes are reserved for what repeats. **A process is built for something that happens once a year.** - Handles it by hand this time and decides next year → No template is maintained for an annual case. **Something urgent is needed and building it would delay the request.** - Requests it directly and records it afterwards → The urgency is served without losing the trail. **A process is built and nobody uses it again.** - Archives templates that are not launched → The list reflects what is actually used. **What began as an exception is now requested weekly.** - Turns it into a process once it repeats → The decision is revisited against real usage. --- --- id: KB-TL-020 url: https://app.codecontract.io/help/trackline/changing-the-contact-mid-file idioma: en categoria: trackline subcategoria: participantes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-010, KB-ET-018, KB-TL-016] citadoPor: [KB-TL-003] --- # Changing the contact mid-file _Your contact leaves, changes role or goes off sick, and the file carries on with half of it delivered._ **Responde a:** changing a file's contact mid-way · the supplier's contact person has left · forwarding what is left to someone else · our contact person has gone It happens in any process lasting more than a fortnight: the person supplying the documentation drops off the map. The file does not stop for that — it carries on with what they already delivered and what is still missing, which now falls to someone else. ## What stays and what changes | Element | What happens when the person changes | | --- | --- | | What was already delivered | It stays, under the name of whoever delivered it | | What is missing | Passes to the new person | | The history of the exchange | Kept: it is what explains where you had got to | | Links sent to the previous person | They remain live until withdrawn | > [!IMPORTANT] > The fourth row is overlooked and has real consequences: **sending the link to the new person does not disable the old one's**. Those are two live ways into the same file, and the departed one sits in a mailbox someone else may inherit, or that they keep if the address was personal. Changing participant is not «emailing the link to the new one»: it is granting access to one and withdrawing it from the other, two separate acts that are nearly always half done. ## The handover, in order 1. **Confirm with the company who takes over** — Do not assume it because someone answered an email. 2. **Add the new person to the file** — With their real address, not the company's generic one. 3. **Withdraw the previous person's access** — The forgotten step, and the only irreversible one if skipped. 4. **And summarise in two lines where things stand** — Delivered, missing and by when: it saves a week. > [!WARNING] > What delays these handovers is not the admin: **it is that the new person does not know what was asked or why**. They inherit a list of documents with no context and start asking things settled a month ago. Two summary lines when granting access are worth more than any later reminder — and if the history lives in the file rather than in the departed person's inbox, those two lines write themselves. ## When it is one of your own who changes **En corto** - The file passes to another team member, and that is recorded. - What was delivered still says who requested and approved it at the time. - And tell the third party their contact has changed: otherwise they write to whoever left. > [!NOTE] > If the change is because someone left the company, check scheduled sends and reminders going out in their name too: those are the ones still arriving weeks later. **Do we have to re-request what was delivered?** No: it stands, delivered by whoever was entitled at the time. **What if the previous person comes back?** Grant access again; the history has not moved. **Can both be active at once?** Yes, during the handover, and it helps: one is withdrawn afterwards. ## Ejemplos **A company emails the link to a supplier's new contact and considers the handover done.** - Adds the new one, withdraws the previous access and summarises the state in two lines → The file moves on without rehashing and with no live access in an unmonitored mailbox. **The contact leaves with the file half done.** - Changes the contact and resends what is outstanding → What was delivered is kept and only the gap is requested. **The new contact does not know what was delivered.** - Shows them the file's status → They catch up without phoning their predecessor. **Reminders keep going to somebody who has left.** - Updates the recipient in the file → Notices reach somebody who can act. **A new file is opened for the new person.** - Continues the existing one, changing the contact → No history is lost and nothing is requested twice. **Nobody knows who the new contact is.** - Asks the company's contact before chasing → The request reaches the right person first time. --- --- id: KB-TL-021 url: https://app.codecontract.io/help/trackline/i-got-a-link-is-it-genuine idioma: en categoria: trackline audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-003, KB-CO-005, KB-TL-026] citadoPor: [KB-PS-021, KB-PR-027, KB-PR-031] --- # I got a link — is it genuine? _Yes, if you were expecting it from that company. And three ten-second checks confirm it without calling anyone._ **Responde a:** i got an email asking for documents is it safe · is the link they sent me fake · how do i know if a document request is phishing · asked to upload papers to a website **Short answer: if you were expecting that company to ask you for paperwork, it is genuine.** A Code Contract email always exists because a specific someone —a client, a contractor, an accountant— started a request addressed to you. It never sends itself. ## The three checks, in ten seconds 1. **Does it say which company is asking, and what for?** — A legitimate request names the sender and the document. A scam tends to be vague and urgent. 2. **Does the link go to codecontract.io?** — Check before tapping — hover on a computer, long-press on a phone. 3. **Is it asking for documents, or for something else?** — Here you upload and sign documents. Passwords, card details and transfers are never requested. > [!IMPORTANT] > **What this system will NEVER ask you for: your email password, card details, a payment, or to install anything.** If a message claiming to be ours asks for any of those four, it is not ours. There are no exceptions and no special cases, so you do not need to weigh up whether this is one. ## If you are still unsure **En corto** - Do not reply to the email: call your usual contact at that company, on the number you already had. - Not the number in the message — that is exactly what a scam would put there. - And if nobody at that company knows what you are talking about, delete it and tell them: someone may be impersonating them. > [!WARNING] > The rare but real case: **a genuine link you were not expecting**. It usually means whoever started it is someone at that company you do not normally deal with —purchasing rather than your usual account manager— or that the request was meant for a colleague and reached you. One phone call settles it, and it is worth making before uploading anything. **Do I have to create an account?** Not to answer a request. You go in through the link. **What if the link has expired?** Ask whoever sent it for a new one. It is not your mistake. **Can I forward it to a colleague?** Yes, but tell the requester: there will be a record of who uploaded what. ## Ejemplos **You receive a document request from a client you do work with, but from someone you have never dealt with.** - Checks the link goes to codecontract.io - Calls their usual contact to confirm who started it → The paperwork goes up with the doubt settled and without having replied to the email. **A similar message arrives asking for your email password «to verify your identity».** - Discards it without tapping anything and warns the impersonated company → The scam is stopped and the impersonated company finds out in time to warn others. **A link arrives and nothing was expected from that company.** - Phones the usual contact before opening it → The check happens through a different channel. **The link asks for data nobody usually requests.** - Stops and checks before entering anything → No data is given to somebody who should not have asked. **The sender address is similar but not identical.** - Compares with earlier emails from that company → The difference is obvious. **The request was expected and everything fits.** - Goes in and uploads what is asked → The delivery is resolved the same day. --- --- id: KB-TL-022 url: https://app.codecontract.io/help/trackline/i-dont-understand-which-document-they-want idioma: en categoria: trackline audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-003, KB-PR-017] citadoPor: [KB-TL-023, KB-PR-028, KB-PR-030] --- # I don't understand which document they want _Just ask. It takes a minute and avoids sending the wrong paper, which is what actually holds everything up._ **Responde a:** i dont know which document they are asking for · asked for a certificate and dont know which · what does this request mean · i dont understand the document request **Ask before sending anything.** Sending «something that looks like it» is what turns a two-day request into a three-week one: it gets reviewed, rejected, re-requested, and by then nobody remembers what it was about. Nobody will think less of you for asking exactly what they want. ## Why you do not understand it (it is rarely your fault) | What is happening | What to do | | --- | --- | | They call it by an internal name of theirs | Ask for an example or what they need it for | | The same paper has three names across sectors | Describe the one you hold and ask if it works | | They ask for something that does not exist in your case | Say so: that is useful information for them | | It was asked by someone who copied the list elsewhere | More common than it looks. Ask anyway | > [!IMPORTANT] > **Saying «I don't have that» or «that doesn't apply to me» is a valid answer and takes the problem off your desk.** What blocks a file for weeks is not a missing document: it is silence. The moment you say it, the ball is in their court — they either substitute it, drop it from the list, or explain why it does apply. ## How to ask so you get a quick answer 1. **Say what you hold, by its exact name** — «I have an X certificate issued by Y in March» gets further than «I don't know which one you want». 2. **Ask what they need it for** — That usually lets you work out which one it is yourself. 3. **And ask through the link, or by replying to whoever sent it** — That keeps it beside the request instead of lost in a separate email. > [!WARNING] > One detail that saves rounds: **if you hold several similar documents, send the one they asked for, not all three**. Attaching everything «just in case» looks helpful and does the opposite: whoever reviews has to decide which one counts, gets it wrong, and you have also handed them documents they never needed and now have to store. **Can I send something similar and let them pick?** That is what delays things most. Ask first; it is faster. **What if I do not have that document?** Say so. It is an answer, and it unblocks. **Who do I ask?** Whoever sent the request: their name is in the message. ## Ejemplos **They ask for «the quality certificate» and you hold three documents that could be it.** - Writes out which three, with names and dates, and asks which they want → The right one goes first time instead of all three plus a rejection round. **They ask for a document that does not exist in your line of work.** - Replies «this doesn't apply to me, and here's why» instead of leaving it blank → The file moves because the request gets corrected, rather than sitting there waiting. **A similar document is sent rather than asking.** - Asks exactly which document before uploading → A whole rejection and resend cycle is avoided. **The document name uses the client's jargon.** - Asks them to describe it in other words → The right document is identified. **Several are requested and one is unclear.** - Uploads the clear ones and asks about the other → The file moves while the doubt is cleared. **The requested document does not exist at their company.** - Says so and proposes the equivalent → The client decides with real information. --- --- id: KB-TL-023 url: https://app.codecontract.io/help/trackline/i-already-sent-you-this idioma: en categoria: trackline audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-022, KB-CF-012] citadoPor: [KB-TL-024, KB-PR-029, KB-TL-026] --- # I already sent you this _You may well have, and they may still need it again: nearly always because it expired or it belongs to another file._ **Responde a:** they are asking for a document i already sent · why am i being asked for the same thing again · i sent you the certificate last year · asked for the same paperwork again **There is nearly always a reason, and it is not that they lost it.** The three usual ones: the one you sent has expired, this request belongs to a different file, or whoever is asking is not the same person or department that asked last time. ## The four reasons, by frequency | What is happening | What to do | | --- | --- | | The previous one expired | Send the current one. The commonest case | | It is for another file | Send it again: it does not copy itself across files | | A different department is asking | Same. And say so, so they know | | They really do hold a current one | Say so with the date: «I sent it on 3 March» | > [!IMPORTANT] > **One sentence resolves all four: «I sent you this document on X — is it still good or would you like a new one?».** With the date in front of them, the requester knows in two seconds whether this is an oversight, an expiry or a different file. Without the date, the exchange becomes two people asserting opposite things. ## What not to do **En corto** - Do not ignore it assuming they already have it: the request stays open and keeps counting. - Do not send the old one without checking the date: if it expired, you will be back here next week. - And do not settle it on the phone with no trace: what is not written down gets asked for again. > [!WARNING] > There is one case where you are entirely right and should still send it: **when each file stands on its own**. A document you uploaded for the warehouse contract does not appear by itself in the new building's file, even though it is the same paper and the same company. It is not that they doubt you — it is simply not there. Sending it takes a minute; arguing about why it should be there takes a week. **Do I have to upload it all over again?** Usually yes, for another request. A minute versus several emails. **What if the one they hold is still valid?** Say so with the date. They check and close the request. **Can I ask them to stop asking?** You can propose they alert you before it expires. It is usually accepted. ## Ejemplos **You are asked for a certificate you sent eight months ago that expired in June.** - Replies with the date of the previous one and sends the current version → The request closes same-day instead of becoming three emails. **The same client asks for the same paper for a different job.** - Uploads it to the new file without arguing that they already hold it → A minute's work instead of a week's conversation about why it should be there. **It was sent a year ago and has expired.** - Checks the document's date before arguing → It becomes clear why it is being requested again. **It was sent to another department of the same client.** - Uploads it to the file that requests it → Each file holds its own. **It was emailed and is not on record.** - Uploads it through the link → It is recorded where everyone sees it. **It is requested again because the document changed.** - Checks whether there is a newer version → The current one is sent rather than the old one. --- --- id: KB-TL-024 url: https://app.codecontract.io/help/trackline/can-i-email-it-instead-of-using-the-link idioma: en categoria: trackline audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-023, KB-PR-020] citadoPor: [KB-TL-010] --- # Can I email it instead of using the link? _You can, but it lands worse: through the link it files itself, by email it depends on someone moving it by hand._ **Responde a:** can i send the documents by email · i dont want to use the link · id rather send it on whatsapp · do i have to upload it to the platform **You can, and nobody will stop you — but the link lands better.** What you upload there goes straight into the file that was waiting for it; what you email has to be opened by someone, matched to a request, and moved across by hand. ## What actually changes | What to look at | Through the link | By email or messaging | | --- | --- | --- | | Where it ends up | In its place, by itself | Wherever whoever opens it puts it | | When it counts as delivered | On upload | When someone processes it | | If you have to show you sent it | On record with its time | Depends on the email being kept | | If they lose it | It is still there | It goes with the email | > [!IMPORTANT] > **The row that matters to you is the third.** The day someone says «you never sent me this», through the link it is on record with a timestamp and there is no argument. By email, your evidence is a message in your sent folder, which is worth far less than it looks once the conversation turns serious. The convenience of an attachment is paid for exactly there. ## When email does make sense **En corto** - When the link has expired and you are waiting for a new one — send it and say so. - When what you want is to ask something, not to deliver a document. - And when whoever handles it specifically asks you to, since they will know why. > [!WARNING] > If you do end up emailing it, one thing is worth doing: **say so in the request itself**. A line like «the certificate went by email to so-and-so, dated today» stops the request sitting open counting days and stops you being chased for something you already did. Half of all annoying reminders are not caused by silence: they are caused by replying somewhere else without saying so. **Is anything lost if I email it?** Nothing is lost, but it depends on a person to reach its place. **What about WhatsApp?** Same, with a greater chance of it staying on someone's phone. **Can I do both?** You can, but say so: otherwise someone reviews the same thing twice. ## Ejemplos **You email the certificate and the request stays open sending you reminders.** - Leaves a line on the request itself saying it went by email, and when → The reminders stop and whoever handles it knows where to look. **Months later someone says that document never arrived.** - Uploads it through the link, where it is recorded with its timestamp → The doubt stops depending on finding an email in a sent folder. **It is emailed and nobody moves it into the file.** - Uploads it through the link → It goes straight to where it belongs. **It is emailed and the sender is not on record.** - Uploads from the link sent to them → The delivery stands in their name. **The email gets lost among twenty others.** - Uses the link for anything that is documentation → The delivery does not compete with an inbox. **It is emailed and the file is too large.** - Uploads through the link, which takes more → Nothing has to be split or compressed. --- --- id: KB-TL-025 url: https://app.codecontract.io/help/trackline/im-not-the-one-who-handles-this idioma: en categoria: trackline audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-027, KB-ET-018] citadoPor: [KB-PR-028, KB-PR-031] --- # I'm not the one who handles this _Say so, and say who does. Forwarding without telling anyone leaves the request in your name — and the reminders too._ **Responde a:** i got a request that isnt mine · a colleague handles this · can i forward the request to someone else · im not responsible for this paperwork **Reply with one line saying who does handle it.** That is all it takes, and it is what stops the request sitting in your name generating reminders for you for weeks. ## The three ways out, best to worst | What you do | What happens next | | --- | --- | | You say who handles it | It gets redirected and the alerts stop | | You forward it silently | It stays in your name. Reminders keep coming | | You do nothing | It piles up and eventually escalates above you | > [!IMPORTANT] > **Forwarding it to a colleague does not take the request off your desk.** It is the option everyone picks because it looks polite and quick, and it is precisely the one that leaves the matter in no-man's-land: you think it is handled, your colleague thinks it was addressed to you, and the requester still sees your name. One line back —«Jane handles this, write to her»— closes all three ends at once. ## If you do not know who handles it either **En corto** - Say so anyway: «I don't know who handles this, try admin» is already a useful answer. - It beats silence, which the requester reads as unwillingness to reply. - And if nobody handles it, that is information too — the kind worth surfacing. > [!WARNING] > The commonest case in small companies: **the request lands at the company's general address because it is the only one on the website**. Nobody is at fault there, it is just a catch-all mailbox. It is worth replying once with the right person and address, because that gets saved and future requests stop passing through — the difference between solving it once and solving it monthly. **Can I just forward it?** Better to also tell the requester, or it stays in your name. **What if the right person is on leave?** Say so with a rough return date: that is what lets people re-plan. **Will I keep getting alerts?** Until the request is redirected, yes. Hence the line back. ## Ejemplos **You receive a request that belongs to another department and forward it saying nothing.** - Replies with one line naming who handles it and at which address → The request is redirected and the reminders stop coming to you. **Every request lands in the company's general mailbox.** - Replies once with the right person and address for this kind of paperwork → Future ones arrive directly and the catch-all stops being a bottleneck. **It is forwarded to a colleague without telling anyone.** - Replies saying who handles it → Reminders stop reaching someone who can do nothing. **The colleague does not handle it either and forwards it on.** - Finds out who does before forwarding → The request reaches its destination in one hop. **The request stays in the name of whoever received it.** - Asks for the contact to be changed in the file → Follow-up points at the right person. **Nobody replies and the client assumes disinterest.** - Replies, even if only to redirect → The relationship does not suffer from silence. --- --- id: KB-TL-026 url: https://app.codecontract.io/help/trackline/three-clients-ask-us-for-the-same-thing idioma: en categoria: trackline audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-023, KB-PR-029] citadoPor: [KB-TL-021] --- # Three clients ask us for the same thing _Build your folder once and answer from it. The work is in gathering, not in uploading._ **Responde a:** several clients ask for the same paperwork · sending the same documents to everyone · how to organise the paperwork clients request · every client asks for their own version **Almost everything you are asked for is the same handful of documents, so the work is done once.** What differs between clients is rarely the content: it is the name they give it and the form it has to go into. ## Your folder, built once | What to keep | With what beside it | | --- | --- | | The documents always asked for | Their expiry date | | The ones that lapse yearly | An alert beforehand, not on the day | | The ones a third party issues | How long they take to issue | | The ones that are hard to obtain | Who to ask and how, so you never rediscover it | > [!IMPORTANT] > **The column that really changes things is the last one: how long each document takes to obtain.** A certificate that takes three weeks is not requested when someone demands it, it is requested beforehand. And that information exists nowhere unless you noted it the first time you had to ask for it — which is exactly when nobody notes it. ## What saves more time than it looks **En corto** - Naming files so they explain themselves: what, whose, and from when. - Keeping the current version and the previous one, not a history of twelve. - Noting who you have already sent them to, and when. - And reviewing the folder once a year instead of every time someone asks. > [!WARNING] > A nuance that prevents sending the wrong thing: **being asked for the same document does not mean it is wanted for the same purpose**. One client wants it to onboard you, another because a third party requires it, a third because an audit is due. When someone asks for something outside your usual folder, the useful question is not «why do you need this?» but «what do you need to be able to demonstrate?» — because what you already hold often serves just as well. **Can I send the same folder to everyone?** The content yes; each will want it through their own route and naming. **Is it worth keeping it tidy?** If more than two clients ask each year, yes, by a distance. **What about documents that expire?** Those are exactly the ones to hold with an alert: that is where the time goes. ## Ejemplos **Three clients request the same paperwork in one month and it is hunted down from scratch each time.** - Builds a folder with the usual set, expiry dates and who issues each item → The second and third requests are handled in minutes rather than days. **A certificate that takes three weeks is requested the day a client demands it.** - Notes beside each document how long it takes to obtain and requests it with margin → Requests stop being answered late because of a lead time that was never yours. **Three clients ask for the same thing and it is prepared three times.** - Keeps its own file current → Every request is served from the same place. **Each client asks in a different format.** - Keeps the original and adapts on sending → The underlying work happens once. **A document expires and three clients must be told.** - Renews once and resends to all three → Renewal does not multiply by clients. **An old version is sent to a client by mistake.** - Always sends from the current file → Everyone receives the same version. --- --- id: KB-TL-027 url: https://app.codecontract.io/help/trackline/the-supplier-who-doesnt-use-email idioma: en categoria: trackline audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-004, KB-ET-003] citadoPor: [KB-TL-010] --- # The supplier who doesn't use email _They exist, more often than you would think, and insisting does not fix it. Finding who on their side does use it, does._ **Responde a:** my supplier has no email · a haulier never answers emails · requesting documents from someone who doesnt use the internet · small supplier with no digital tools A self-employed haulier, a two-person workshop, a long-standing supplier who works off a mobile and little else. You send the request, no reply, you chase, and you end up phoning them and writing down what they tell you. It is neither bad faith nor neglect: that channel is simply not part of their day. ## Who tends to be behind that kind of silence | Situation | What actually works | | --- | --- | | Does not use email, but does use their phone | Send the link by message, not by email | | Their accountant handles it | Ask the accountant, with their permission | | A relative or partner handles it | Ask who deals with the paperwork | | On the road all day | A realistic deadline beats three reminders | > [!IMPORTANT] > **The question that solves 80 % of these cases is «who handles the paperwork?».** Almost nobody asks it, because it is assumed that whoever does the work is whoever sends the papers — and in small firms it is rarely the same person. Asking once, noting the name and the channel, and using it from then on turns an impossible supplier into an ordinary one. ## What does not work, however often it is repeated **En corto** - Chasing through the same channel that has already failed three times. - Explaining how to use a tool they are never going to use. - Assuming that no reply means unwillingness to cooperate. - And keeping what they tell you on the phone only in your head. > [!WARNING] > If you end up collecting the paperwork by phone or on paper —which is sometimes the only option— one thing is worth doing: **upload it to the file yourself and record where it came from**. A document that exists only in a drawer or as a photo on someone's phone does not exist: when you need it there will be a problem on, and that day nobody will remember which drawer. > [!NOTE] > None of this releases the supplier from their obligations or you from yours: what changes is the route the paper takes, not what has to be held. **If the relationship requires specific documentation, that stays the same**; here we explain how to obtain it from someone who is not going to log into a screen. **Can I upload their documentation myself?** Yes, and it is sensible if they give it to you another way. Record who provided it. **What if they refuse to provide the papers?** That is no longer a channel problem: it is a commercial decision of yours. **Is it worth pushing them onto the tool?** With volume yes; with a supplier of two orders a year, rarely. ## Ejemplos **A self-employed haulier does not answer three emails in a row.** - Phones to ask who handles their paperwork and sends the link by message → The documentation arrives in two days, through the channel that person actually uses. **A supplier hands over certificates on paper and they stay in a physical folder.** - Uploads them to the file and records where they came from and who provided them → The document exists on the day it is needed, which is always a bad day. **The supplier does not read email and gets chased there anyway.** - Finds somebody on their side who does use it → The delivery arrives by a route that works. **They only respond by phone.** - Phones them and uploads on their behalf with their permission → The file moves with a record of what was discussed. **They send photos by messaging app.** - Sends them the link through that same channel → Uses the channel they already use rather than a new one. **The company has an accountant who handles their paperwork.** - Sends the request to the accountant with their permission → The document comes from whoever holds it. --- --- id: KB-TL-028 url: https://app.codecontract.io/help/trackline/how-this-differs-from-a-document-management-tool idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-23 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-019, KB-TL-029] citadoPor: [KB-TL-019, KB-TL-030] --- # How this differs from a document management tool _A document manager stores what you already have. Here the work is getting what you do not have yet, and it is held by someone who does not work for you._ **Responde a:** difference between a document manager and trackline · we already have a shared folder for this · why do we need this if we already have a document repository · what does it add over asking for documents by email **A document manager solves the problem of finding what you already have. This one solves getting what you do not have yet.** Two different jobs, rarely done by the same tool, because the second depends on someone outside your organisation who has no account in your systems and no obligation to learn them. ## Where the work sits, in each case | The work | Document manager | Here | | --- | --- | --- | | Where the document is | You already have it | A third party has it | | Who acts | Someone inside | Someone outside | | The typical problem | Finding it | Getting it to arrive | | What success means | It is filed | **Nothing is missing and it is on record who provided it** | > [!IMPORTANT] > **The practical difference is who does the chasing.** In a shared folder, when a certificate is missing nothing happens: the folder does not warn you, does not know it is missing, and cannot know, because it does not know what should be there. Someone on your team has to remember, look, write the email and look again next week. That work — remembering and looking again — is the part a person no longer does here. ## The five things that change **En corto** - **Whoever responds needs no account.** They open a link, upload, done. Asking them to register is where half the responses are lost. - **The channel is chosen by the person answering**, not by the one asking: email, WhatsApp, SMS, a call or the portal. The supplier who never opens email does read messages. - **Status belongs to the case, not the file**: what is missing, from whom, and since when, on one screen. - **What arrives is reviewed and extracted**, not just stored. An expired certificate that has been filed is still expired. - **And there is a record of who provided what and when**, which is different from having the file in a folder. ## When the document manager is what you need 1. **When the document is already yours** — Signed contracts, manuals, internal policies. There is nothing to request. 2. **When the problem is search and permissions** — High volume, many versions, who sees what. That is a repository's job. 3. **And when they coexist, which is the normal case** — This handles the outside stretch; what is already closed lives where it always did. > [!WARNING] > The most expensive starting mistake is treating this as «a folder with reminders». Set it up that way — a list of documents someone ought to upload — and you end up with what you had plus a tool in the middle. **What changes the outcome is defining what is requested, from whom and by when**, because from then on the system knows what is missing and can chase it on its own. Without that definition there is nothing to chase. **Does it replace our repository?** No. It handles getting the document; long-term storage can stay where it is. **What if asking by email already works?** Then you do not have the problem. It usually shows up going from ten requests to a hundred. **Can we export what we collect?** Yes, the whole case. No data is trapped in here. ## Ejemplos **An accountancy firm keeps everything in per-client folders. For a group insurance renewal it needs the same certificate from 140 companies and builds a spreadsheet to track who has sent it.** - Turns the spreadsheet into a one-document template - Launches to all 140 at once - Watches the status screen instead of the spreadsheet → The spreadsheet disappears: who has sent and who has not sits on the same screen as the requests, and updates itself. **A purchasing team has an immaculate repository, yet 30 % of new suppliers take over three weeks to onboard because a document is always missing and nobody knows which.** - Defines onboarding as a case with its six documents - Lets the system ask and remind - Reviews only what arrives → Three weeks become four days, and what is missing is visible without asking anyone. **A construction firm shares a cloud folder with twenty subcontractors. Two months in there are 400 files named things like «scan_2.pdf» and nobody knows which belong to the company starting tomorrow.** - Requests each document against a specific requirement and company - Stops accepting loose uploads - Closes the shared folder to new files → Every file arrives already knowing whose it is and which requirement it meets: the filename stops mattering. **A quality manager finds during an audit that she has the supplier's certificate but cannot show when it was provided or who sent it.** - Collects by request from now on, not by email - Lets the delivery record build itself - Attaches that record to the audit file → Next audit, «when did they give it to you?» is answered on screen instead of by reconstructing an email thread. **A company receives documents by email and drags them into the folder by hand. The person who does it goes on holiday for two weeks.** - Replaces the manual dragging with link-based collection - Splits follow-up between two people - Checks status on return → The two weeks stop being a hole: what arrived is filed and what is missing is still being chased. **A small supplier barely uses email and answers on WhatsApp. The shared folder is not even an option for him.** - Sends the request over WhatsApp - Receives a photo of the document from his phone - The photo enters the case like any other delivery → He stops being the impossible supplier: he answers where he already answers, and it lands in the same place as everything else. **A 12-person company pays for a repository almost nobody opens, because the real work — chasing those who do not send — still lives in two people's inboxes.** - Leaves the repository for closed archives - Moves collection to requests with automatic reminders - Measures how many manual reminders remain → Manual reminders drop to almost zero, and the repository starts receiving documents that have already been checked. **Migrating document systems, the team discovers that who delivered what lived in the emails, not in the repository, and does not migrate.** - Separates the archive (files) from collection (who, when, against what) - Lets collection keep its own trail - Exports the whole case, not just the files → The next migration carries the traceability too — the half that always used to be lost. --- --- id: KB-TL-029 url: https://app.codecontract.io/help/trackline/how-this-differs-from-an-ai-agent idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-23 tambienEn: [es] relacionados: [KB-TL-015, KB-MA-013, KB-TL-030] citadoPor: [KB-TL-028, KB-TL-015, KB-MA-005] --- # How this differs from an AI agent _An agent writes and chases very well. What it cannot do is make the other side answer, or turn a generated answer into a document that counts._ **Responde a:** why not build an ai agent to request the documents · difference between an ai agent and trackline · can ai chase suppliers for me · automating document requests with ai **It is a fair question, and the short answer is that there is AI here too — what changes is where it sits.** An agent that drafts the request, decides who to nudge and summarises what arrives does real work. The problem is that the hard part of this process is neither drafting nor remembering: it is getting the document out of a third party's hands and in through a route you can later prove. ## What an agent solves and what it does not | Job | An agent does it | Something else is needed | | --- | --- | --- | | Drafting the request | Yes, and well | — | | Deciding who to nudge today | Yes | — | | Reading and summarising what arrives | Yes | — | | **Arriving through a channel they use** | No | Real multi-channel sending | | **Knowing who delivered it and when** | No | The system's own record | | **The team seeing the same status** | No | A shared case | > [!IMPORTANT] > **A model generates text; a case needs documents.** Everything else hangs off that distinction. Ask an agent for a company's certificate and what it can give you is what it knows or finds — never the document that company holds and has not handed over. And an answer that sounds like a certificate does not count as one for anybody: not a customer, not an auditor, not a court. ## The silent failure, which is the one to know about 1. **The agent assumes it already received it** — The classic failure: it believes a task completed and closes it with nobody confirming. 2. **And nobody notices until it matters** — The gap surfaces in the audit or the meeting, not on the day it happened. 3. **So status is not declared by the requester** — A document counts as delivered when it arrives, not when someone says it did. ## Where the AI is here **En corto** - **Building the process**: describe what you need and the template proposes itself, phases and documents included. - **Reading what arrives**: it extracts the data and flags what does not add up, instead of leaving you 40 PDFs to open. - **Answering questions** about your cases, through Marta, which consults what exists rather than inventing it. - **And it stops there**: AI speeds up the work around the document. The document, and the proof of who provided it, are not generated. > [!WARNING] > There is one case where your own agent is the answer: **when the process is entirely internal and does not depend on anyone outside replying**. Drafting, cross-checking data you already hold, watching expiry dates on what is already filed. That needs no channel, no identity for the responder and no delivery trail — the three expensive things to build, and the ones that make this not an agent. > [!NOTE] > What a system can attest about a delivery — and what weight that carries in a particular procedure — **depends on the applicable framework and is for your adviser to confirm**. What is explained here is operational: that it is on record who delivered what and when, and that the record does not depend on someone remembering to note it. **So you do not use AI?** We do, in three places: building the process, reading what arrives and answering questions. **Can I connect my own agent?** Yes, through the API. What you should avoid is letting it declare delivery status. **Does AI decide on its own whether a document is valid?** No. It proposes and flags; a person approves or rejects. ## Ejemplos **A team builds an agent that emails suppliers asking for certificates. Three weeks in it has sent 260 emails and cannot say how many documents came back.** - Lets the agent draft and prioritise - Moves sending and receiving into the case - Measures deliveries, not emails sent → The metric shifts from «emails sent» to «documents missing», which is the one that says whether the work is moving. **An agent summarises a supplier reply as «confirmed they will send the certificate». Two months later, in the audit, the certificate is not there.** - Stops accepting confirmations as status - Requires the document to arrive before closing the requirement - Reviews which other requirements closed the same way → Seven more requirements turn out to have closed on a promise rather than a document — in time to request them. **A company wants AI to validate its subcontractors' insurance and finds the hard part is not reading the policy but getting them to send it.** - Uses AI to read and check cover and dates - Uses the process to request and chase - Approves the doubtful ones by hand → Automatic reading stops idling while it waits for documents that never arrived. **A manager asks a general assistant for «this company's tax clearance certificate» and receives a very convincing explanation of what that certificate is.** - Separates explaining from obtaining - Sends the request to whoever holds the document - Stores what arrives → The explanation stops being mistaken for the document — the mistake that costs a week. **An accountancy firm automates reminders with AI and still has the same 20 % of clients who never answer email, however much they are chased.** - Switches that 20 % to WhatsApp or SMS - Leaves reminders where they work - Compares response by channel → The 20 % that was a channel problem, not a persistence problem, starts answering. **A technical team connects its own agent through the API to launch processes from their ERP.** - Lets the agent create and launch the process - Leaves status and trail to the system - Reads the result back into the ERP → The ERP triggers the work and receives the outcome, with nobody declaring by hand what arrived. **Someone asks Marta about a figure in a case and Marta answers citing the document and the date it arrived.** - Asks in plain language - Checks the source it cites - Opens the document if the detail matters → The answer can be verified in two clicks, which is what separates it from a generated one. **A management team considers replacing the process with an in-house agent and asks for a list of what they would have to build.** - Lists channel, responder identity and delivery trail - Prices each one - Decides with that list in front of them → The decision stops being «AI or not» and becomes which three pieces to build and what they cost. --- --- id: KB-TL-030 url: https://app.codecontract.io/help/trackline/how-this-differs-from-a-bpm idioma: en categoria: trackline subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-23 tambienEn: [es] relacionados: [KB-TL-002, KB-TL-028, KB-TL-018] citadoPor: [KB-TL-014, KB-TL-029] --- # How this differs from a BPM _A BPM models what happens inside your company, with people who answer to you. Here half the process is outside and does not._ **Responde a:** difference between a bpm and trackline · we already have a process engine can we do it there · modelling document requests in the bpm · workflow for requesting supplier documentation **A BPM is very good at what it does: modelling a process with many branches, many roles and many systems, all inside your organisation.** Every participant has an account, an assigned task and a manager. The process moves because someone inside moves it. ## Where the analogy breaks | What is taken for granted | Internal process (BPM) | Collecting from third parties | | --- | --- | --- | | Who performs the task | An employee | Someone at another company | | Has an account and training | Yes | No, and never will | | Can be assigned work | Yes | **No: they can be asked** | | If they do not do it | Escalate to their manager | **There is nobody to escalate to** | | The real bottleneck | Coordination across teams | **Silence from the other side** | > [!IMPORTANT] > **Modelling the external stretch in a BPM usually ends in a task called «wait for supplier document» that sits there for weeks.** The engine creates it, assigns it to someone inside, and waits. But that person does not have the document: all they can do is write an email and look again — exactly the manual work the BPM was meant to remove. The diagram is perfect and the process does not move. ## What the outside stretch needs **En corto** - **Reaching people where they answer**: email, WhatsApp, SMS, a call or a link, without making them register. - **Persistence owned by the system**, on its own schedule, not a task in somebody's inbox. - **Status that updates on receipt**, not when a person types it in. - **And a trail of who delivered what and when**, because that is what you will be asked later. ## When the BPM is the right tool 1. **When the process is internal and branching** — Approvals by amount, routing by department, integrations with several systems. 2. **When the business rules are complex** — Conditions, exceptions, internal deadlines. That is what a BPM is for. 3. **And when they coexist, which is the usual case** — The BPM runs the internal process and calls this one for the external stretch, via API. > [!WARNING] > The honest comparison is not «one or the other» but **how much of the process is outside your control**. If it is small — one document at the end — the BPM can carry it. If it is half the process, across fifty companies with fifty ways of working, that half needs something else. And there is an easy signal: if your process has tasks sitting more than two weeks waiting on someone outside, that is the part being discussed. > [!NOTE] > Setting this up needs no implementation project and no modelling: a template is defined in an afternoon and launched the same day. If your BPM is already running, the normal move is to leave it alone — the external stretch is added over the API and the internal diagram stays as it is. **Does it replace our BPM?** No. It handles the stretch that leaves the company; the internal part stays where it is. **Can they be connected?** Yes, over the API: the BPM launches the process and receives the result. **What if our process is entirely internal?** Then the BPM is enough. This starts to pay off once third parties are involved. ## Ejemplos **A manufacturer models supplier onboarding in its BPM and the «receive documentation» task piles up 40 instances older than a month.** - Takes that task out of the BPM - Replaces it with a call to the external process - Lets the BPM wait for the result → The 40 stalled instances start being chased by the system, and the BPM is notified when documentation is complete. **A process team costs out modelling WhatsApp sending and a portal for unregistered users inside the BPM.** - Lists channel, identity and trail - Compares with connecting over the API - Presents both figures → The comparison stops being a matter of opinion: it is visible which part is worth building and which is not. **A company has purchase approval beautifully modelled in its BPM and wants to add supplier document onboarding.** - Leaves approval where it is - Adds the documentation stretch as a prior step - Connects the two over the API → Approval is untouched and stops starting with incomplete documentation. **A manager finds the BPM marks a process complete because someone manually closed the waiting task, with no document ever arriving.** - Removes the ability to close that step by hand - Ties closure to the document actually arriving - Reviews last quarter's closures → The cases closed without a document surface — exactly what the audit was going to find. **An organisation with no BPM considers buying one to solve subcontractor document collection.** - Separates which part is internal and which external - Confirms nearly all the problem is outside - Starts with the external stretch → The real problem is solved without opening an implementation project that would take months. **A BPM launches the document process over the API and needs to know when it is complete in order to continue.** - Launches the process from the BPM - Listens for the completion notice - Continues the internal flow → The internal process advances only when documentation genuinely exists, not when someone says so. **The quality team wants one dashboard for internal and external alike.** - Leaves internal metrics in the BPM - Takes what is missing and since when from the external process - Combines both in the report → The dashboard separates what jams inside from what jams outside — they are fixed in different ways. **A consultancy proposes modelling the entire process, third parties included, over a six-month project.** - Splits off the external stretch and runs it this week - Measures what improves - Decides later what still needs modelling → The painful part stops hurting while the decision about what deserves a project is made with data. --- --- id: KB-TL-015 url: https://app.codecontract.io/help/trackline/letting-the-ai-build-the-process idioma: en categoria: trackline subcategoria: plantillas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-006, KB-TL-029] citadoPor: [KB-TL-018, KB-TL-029] --- # Letting the AI build the process _Describe what you need in a sentence and get a draft to correct._ **Responde a:** create a process automatically · i do not know what documents to ask a supplier for · let ai design the process · automatic process template What stops most people at the start is not the tool: it is not knowing what to ask for. You can describe what you need in a sentence and come away with a draft process built, which you then correct. ## How to use it 1. **Describe what you need: "subcontractor onboarding for a site, with company and worker documentation".** 2. **A draft appears with phases and requests.** 3. **You correct it: remove what does not apply, add yours, adjust what blocks.** 4. **Save it as a template.** > [!IMPORTANT] > It is a draft, not a finished template. What it proposes are the usual documents for that case, not those your regulations require or your customer demands. Review it with that in mind before using it with anyone outside. ## What it is really for Not to avoid thinking, but to avoid starting from a blank screen. Correcting a list that already exists is much faster — and comes out better — than inventing one, especially the first time. > [!WARNING] > Whatever it proposes has to pass through someone who knows your case. If the process ends up asking for documents you do not need, you will annoy your suppliers; if it misses a mandatory one, the problem is worse. > [!NOTE] > Designing a schema with AI consumes the same as creating the process by hand. Using it costs no more. **Can I change everything afterwards?** Yes, it is a starting point. **Does it get my sector's documentation right?** It usually gets the usual items right; the specific ones you add yourselves. **What if I prefer building it by hand?** Perfectly valid, and from the second process onward it is usually faster. ## Ejemplos **Someone has to build their first process and does not know what to ask a subcontractor for.** - Describes it in one sentence - Corrects the draft, removing two documents and adding one of their own → Comes away with a usable process in ten minutes instead of abandoning it at the blank screen. **Building the first template from scratch feels like a chore.** - Describes in one sentence what needs requesting → A draft comes out that only needs correcting. **The draft includes documents that do not apply.** - Removes what is superfluous before saving → The final template is shorter than the draft. **The draft uses generic names.** - Rewrites them in their sector's vocabulary → The supplier understands what is being asked. **The draft is saved without review.** - Reviews it fully before launching to anyone → No supplier receives a nonsensical request. **A variant is needed for another supplier type.** - Describes the variant and adjusts the new draft → The second template takes minutes. --- --- id: KB-CO-013 url: https://app.codecontract.io/help/consigne/what-the-recipient-actually-sees idioma: en categoria: consigne subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-005, KB-GL-002] citadoPor: [KB-CO-015, KB-CL-001, KB-IN-004] --- # What the recipient actually sees _The screen more people see than any other, described step by step._ **Responde a:** what the signer sees when opening the link · what the external portal looks like · can the supplier see other documents · what does what i send look like For every person on your team who enters the platform there are twenty who only ever see one screen: the one the link you sent them opens. It is worth knowing what is on it, because it is the impression they take away of your company. ## What they see, in order 1. **Who is writing** — Your name and your company's, at the top. With your own branding configured, in your colours and logo. 2. **What you are asking for, as a list** — Only their part. They do not see the whole case or other participants' items. 3. **What is mandatory and what is not** — Marked. That is what lets them deliver what they have without being blocked by what they do not. 4. **A button to upload or sign** — And nothing else. No sign-up, no password, nothing to install. ## What they do NOT see - Other participants' documents, even in the same case. - Your internal notes or comments. - Your other suppliers or clients. - Anything about your organisation beyond what you asked them for. > [!IMPORTANT] > That separation is hard, not a setting: two subcontractors on the same case cannot see each other. It is what lets you ask them for sensitive documentation without them sharing anything. > [!WARNING] > Each request's title is the only thing explaining what you want. "Doc 3" leaves them guessing; the document's full name is understood first time. > [!NOTE] > Send yourself the link the first time you build a process. It takes a minute and changes how you write titles quite a lot. **Does it work on a phone?** Yes, and that is where most people open it. **Does the link expire?** It has a deadline; a new one can be sent immediately. **Can they come back later?** Yes, with the same link, and they see what they already delivered. ## Ejemplos **A company builds its first process and sends itself the link.** - Sees its titles read "Doc 1", "Doc 2" and "Cert" - Rewrites them with each document's full name → Suppliers stop delivering the wrong document from the very first send. **The recipient cannot tell whether the email is genuine.** - Includes recognisable context in the notice → It gets opened rather than dismissed. **The recipient cannot find the sign button.** - Checks how it looks on a small phone → The path works on the real device. **The notice text uses internal jargon.** - Rewrites it for somebody who does not know you → Clarification calls drop. **The recipient opens it and does not know what to do next.** - Makes the next step clear on screen → The process completes unaided. **Nobody on the team has ever seen that screen.** - Sends themselves a request → You know what the other side sees. --- --- id: KB-CO-014 url: https://app.codecontract.io/help/consigne/scheduling-a-send-for-later idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-010, KB-TL-013] citadoPor: [KB-CO-017, KB-CC-016] enLaApp: https://app.codecontract.io/consigne --- # Scheduling a send _So it goes out when it should, not when you happen to have a moment._ **Responde a:** schedule a document send · send a contract on a specific date · have it go out monday morning · automatic renewal sends Preparing something on a Thursday afternoon so it goes out Monday at nine is not convenience: it is the difference between being read and being lost among weekend email. **En corto** - Prepared when you can, sent when it suits. - It can be cancelled or corrected while it has not gone. - Anything tied to a date — a renewal, an expiry — is scheduled once and repeats. ## When scheduling helps | Situation | When to send | | --- | --- | | An amendment for the whole workforce | Tuesday or Wednesday morning | | An annual renewal | On the right day, even if it is a holiday for you | | Something depending on a prior signature | When that signature exists, not before | | Documents to a new client | Immediately; waiting adds nothing here | _Friday afternoon is the worst moment for almost anything requiring someone to act._ ## What can change before it goes - The document, if you have spotted an error. - The recipients, if someone is missing or surplus. - The date, as often as you like. - Cancelling entirely, leaving no trace for the recipient because it never reached them. > [!WARNING] > Scheduling and forgetting carries a risk: it goes out after the situation has changed. If you schedule more than two weeks ahead, set yourself a reminder to review it first. > [!NOTE] > Scheduling the annual renewal on the same date each year means third parties expect it. That raises delivery more than anything you can write in the email. **What if the date is a public holiday?** It still goes; if that matters, move the date when preparing. **Can I schedule reminders as well as the send?** Yes, the rhythm is set when scheduling. **Is the credit taken at scheduling or at sending?** At sending, which is when it actually goes. ## Ejemplos **A company prepares eighty employee amendments on Thursday.** - Schedules them for Tuesday at nine → Open rates are far higher than the previous round, sent at six on a Friday evening. **A notice goes out on a Friday at seven in the evening.** - Schedules the send for Monday morning → The notice arrives when somebody can act on it. **An annual renewal is sent whenever somebody remembers.** - Schedules the send with the needed lead time → Renewal stops depending on memory. **A campaign is prepared and must launch on set dates.** - Leaves it scheduled while preparing it → It goes out on the date even if that day brings something else. **It is scheduled and then the recipient changes.** - Reviews what is scheduled before it goes → No notice goes to somebody who no longer applies. **Sends are scheduled in August.** - Adjusts dates to the sector's calendar → Response rates do not collapse. --- --- id: KB-CO-001 url: https://app.codecontract.io/help/consigne/sending-a-document-for-signature idioma: en categoria: consigne subcategoria: enviar modulo: consigne audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-001, KB-CO-002, KB-CO-003, KB-CO-004, KB-CO-021] citadoPor: [KB-PS-001, KB-CO-002, KB-CO-003, KB-CO-004, KB-CO-007, KB-CO-010, KB-CO-011, KB-CR-002, KB-CR-003, KB-CS-005, KB-CF-004] enLaApp: https://app.codecontract.io/consigne/new --- # How to send a document for signature _Upload the document, say who signs and at what level, and get the signed PDF with its evidence._ **Responde a:** how do I send a document for signature · electronic signature for contracts · send a contract to several signers · does the signer need an account · what is Consigne Consigne is for getting someone to sign a document in a way that holds up afterwards. It is not "send a PDF and get it back scanned": what comes out at the end is a document with the signature embedded, the date certified and a record of who signed, when and from where. **En corto** - The signer needs no account: they open a link, sign with a finger or mouse, done. - There are two signature levels; the second adds a code by SMS. - If several people sign, you decide whether they go in order or all at once. - You can see who has signed and who has not at any moment. - The final PDF validates without depending on Code Contract. ## How to send one, step by step 1. **Go to Consigne and click "New signature request"** — You can also start from a folder if you already know where you want it filed. 2. **Upload the document** — Usually a PDF. Other formats are converted to PDF so they can be signed. 3. **Add the signers** — Name, email and phone for each. The phone is needed if you are going to require advanced signature. 4. **Place where each one signs** — Drag the signature box onto the PDF, on whichever page and spot you want. Each signer gets their own. 5. **Choose the level and the order** — Simple or advanced signature per person, and if there are several, whether they sign in sequence or at once. 6. **Set the optional bits and confirm** — Deadline, automatic reminders, a personal message per signer, and who gets a copy of the closed document. > [!WARNING] > Check the document before sending. Once it is out, a mistake means cancelling the request and starting again: the file cannot be swapped underneath, because then the signature would prove nothing. ## When several people sign: in order or at once **Sequential versus parallel** — In sequential, each signer gets their notice once the previous one has signed. In parallel they all get it at once and the document closes on the last signature. Pick order when it matters who signs first — the employee before management, the tenant before the landlord — and all-at-once when it does not and you just want it finished. ## Tracking the status While the request is open you can see where each person is: whether it was sent, whether they opened the link, whether they signed or rejected it. From there you can send a manual reminder without waiting for the automatic one. | Status | What it means | What you can do | | --- | --- | --- | | Sent | The notice went out and nobody has opened it yet | Wait or remind | | Opened | Someone opened the link but has not signed | Remind; usually means doubts | | Partially signed | Some have signed, others have not | Remind only those left | | Completed | Everyone has signed | Download the PDF and its evidence | | Rejected | A signer refused, with their reason | Fix it and send again | | Cancelled | You stopped it | Create a new one | | Expired | The deadline passed | Send again with a new date | ## Frequently asked questions **Does the signer have to create an account?** No. They get a link and sign from a phone or computer without registering anywhere. **Can I also ask them to fill something in?** Yes. You can add fillable fields on the document — a date, a bank account, a consent checkbox — and the signer completes them before signing. **Can I send several documents in one request?** Yes, several documents can go in the same signature request so the person signs them in one go. **What happens if someone refuses to sign?** The request is marked rejected, with whatever reason they gave, and nobody else signs. You fix what needs fixing and send a new one. **Can I cancel a signature already sent?** Yes, as long as it is not completed. The links stop working and the record shows that you cancelled it and when. ## Ejemplos **HR is onboarding someone on Monday and needs the contract signed before they start.** - Uploads the contract and adds two signers: the new hire and management - Sets advanced signature for the new hire and sequential signing - Turns on an automatic reminder after 24 hours → On Monday there is a PDF signed by both parties, timestamped and with proof of who signed and from where. **Documents are emailed for signature and nobody knows who has signed.** - Sends the document and checks each signer's status → Follow-up stops being a chain of emails. **Four people from two companies must sign.** - Adds all four signers to the same send → Everyone signs the same document and one final copy remains. **The signer has no certificate and will not install anything.** - Picks the level that does not require one → It is signed the same day from the browser. **It is signed on paper and then scanned.** - Sends the PDF for signature directly → The print, sign and scan round trip disappears. **The signed document is needed to attach to a file.** - Saves the result in the relevant file → The signature ends up where it will be looked for. --- --- id: KB-CO-002 url: https://app.codecontract.io/help/consigne/simple-or-advanced-signature-which-to-choose idioma: en categoria: consigne subcategoria: firmantes modulo: consigne audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-004] citadoPor: [KB-CO-001, KB-CO-003, KB-CO-004, KB-CO-005, KB-CR-003, KB-SC-018] --- # Simple or advanced signature: which to choose _The two available levels, how they actually differ and when each one is worth it._ **Responde a:** difference between simple and advanced signature · which electronic signature level do I need · signature with SMS OTP · is a simple electronic signature legally valid The difference between the two levels is not the look of the signature — that is the same — but how much is checked about whether the signer is who they claim to be. And that is exactly what gets argued about if someone ever denies having signed. **En corto** - Simple: the person draws their signature. Where and when they did it is recorded. - Advanced: they must also enter a code sent to their mobile. - The cost of advanced is one SMS and thirty extra seconds for the signer. - Reasonable doubt is the only thing that decides: could this end up disputed? ## How they differ | What to look at | Simple signature | Advanced signature | | --- | --- | --- | | What the signer does | Draws their signature with a finger or mouse | The same, plus typing a code received by SMS | | What gets verified | That whoever opened the link signed | Also that they control that mobile number | | What you need from them | An email or a phone | A valid mobile, necessarily | | How long it takes | Under a minute | About a minute and a half | | Where it fits | Acknowledgements, consents, internal documents | Contracts, NDAs, agreements with money involved | ## How to decide without agonising Ask yourself one question: if in two years this person said "I never signed that", would I care? If nothing much would happen, simple signature. If you would have a problem, advanced. > [!NOTE] > It is chosen per signer, not per document. You can require advanced from the client and simple from the person on your team who signs off. ## What is NOT supported today Worth knowing before promising it to a client: there is no qualified signature with a certificate (the equivalent of signing with a national eID or a certificate authority), no identity verification by photographing an ID document, and no authenticator-app codes. The available levels are the two above. ## Frequently asked questions **Is a simple signature legally valid?** Yes — an electronic signature cannot be rejected merely for being electronic. What changes between levels is how easy it is to defend if somebody disputes it. **What if the signer has no mobile?** Then they cannot complete an advanced signature, because the code goes by SMS. For that person you have to use a simple signature. **Can I change the level after sending?** Not on a request already sent. You would cancel it and create a new one with the right level. **Does the SMS code expire?** Yes, it is short-lived for security. If it lapses, the signer can request another from the same link. ## Ejemplos **A sales rep closes a €40,000 contract with a new client they have never met in person.** - Sets advanced signature for the client's signer - Leaves simple signature for the internal manager signing off - Checks the client's mobile number before sending → If the client ever disputed the contract, there is a record that the code reached their mobile and was used to sign. **The highest level is required for everything by default.** - Checks which documents genuinely need it → The rest is signed the same day. **A supplier cannot obtain a certificate and the process halts.** - Separates what needs the high level from what does not → What can move, moves. **Nobody knows what proof each level leaves.** - Compares what is recorded in each case → The choice rests on the real difference. **A low level is chosen for a document with a lot at stake.** - Raises the level where the risk justifies it → The level matches the document's value. **The level is changed midway through a process.** - Decides the level before sending → Nothing has to be cancelled and resent. --- --- id: KB-CO-003 url: https://app.codecontract.io/help/consigne/what-the-signer-sees idioma: en categoria: consigne subcategoria: firmantes modulo: consigne audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-002, KB-CO-016] citadoPor: [KB-CO-001, KB-CO-009, KB-CO-022] --- # What the signer sees _The whole journey from the other side, and the two points where people get stuck._ **Responde a:** what does the signer see · the SMS code to sign is not arriving · how do you sign from a phone · can the signer refuse to sign Nearly every signature that stalls does so because of something happening on the signer's screen, not yours. It is worth knowing exactly what they see. **En corto** - They get a personal link by email, SMS or WhatsApp. - They see the whole document before signing, not just the signature box. - They sign by drawing with a finger on a phone or with the mouse on a computer. - They receive a copy of the signed document once it closes. ## The journey, step by step 1. **They open the link** — No registration, no password. The link already knows who they are and which document they must sign. 2. **They read the document** — They see the full PDF, can page through it and download it before deciding. Your message, if you wrote one, is there too. 3. **They fill in any fields** — If you added fields for them to complete — a date, a number, a checkbox — those are asked for before they are allowed to sign. 4. **They draw the signature** — A box where they trace their signature with finger or mouse. They can redo it as often as they like before accepting. 5. **They confirm with the code, if it is an advanced signature** — An SMS arrives at the mobile you recorded. They enter the code and that completes the signing. 6. **They see the confirmation** — It is clear they have finished, and once everyone has signed they receive a copy of the closed document. ## The two places people get stuck The first is the SMS on advanced signatures: if the number is mistyped or is a landline, the code never arrives and the person is stranded without knowing why. That is why it pays to check phone numbers before sending. The second is mandatory fields. If you added fields that must be filled in and it is not obvious what goes in them, people give up. An explicit label on each field fixes it. > [!NOTE] > If somebody tells you "it does not work", the first thing to check is whether the link they opened was their own: links are personal and another signer's will not do. ## Frequently asked questions **Can they refuse to sign?** Yes, and they can leave a reason. The request is marked rejected and you see it with their explanation. **Can they sign from a phone?** Yes, and that is the most common case. They sign with a finger, installing nothing. **Do they keep a copy?** Yes. When the document closes, they are sent a copy of the signed PDF. You can also add other people as recipients of that copy. **Can they see who else has to sign?** They can see the document has several signers, but their link only works for their own signature. ## Ejemplos **A firm sends an NDA for signature and the client replies by email saying no code is arriving.** - Checks the phone number recorded for that signer on the request - Sees it is a landline, not a mobile - Cancels, fixes the contact and sends again → The client signs within five minutes, instead of the NDA ending up emailed back as a scan. **The signer looks for where to register.** - Explains they sign from the link with no account → They sign there and then. **The signer cannot see where to sign in the document.** - Places the signature fields before sending → The path is obvious without explanation. **The signer receives the code and does not know what it is for.** - Explains the step in the notice itself → The second factor stops being an obstacle. **It is sent for signature without seeing the signer's side.** - Sends the document to themselves first → Sticking points surface before reaching anyone. **The signer wants to read it carefully before signing.** - Tells them they can open it and come back → They do not sign in a hurry for fear of losing the link. --- --- id: KB-CO-004 url: https://app.codecontract.io/help/consigne/what-you-are-left-with-as-evidence idioma: en categoria: consigne subcategoria: prueba modulo: consigne audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-002, KB-SC-001] citadoPor: [KB-CO-001, KB-CO-002, KB-SC-003, KB-CR-004, KB-CO-018, KB-CO-020, KB-CO-021, KB-CR-006, KB-TZ-001] enLaApp: https://app.codecontract.io/verify/search --- # What you are left with as evidence when it finishes _The signed PDF, the timestamp, the evidence chain and how a third party checks it._ **Responde a:** how do I prove someone signed a document · what evidence remains from an electronic signature · verify a signed document · does the signature hold if I stop being a customer Signing is half the job. The other half is being able to prove it three years later, when nobody remembers and you may not even be using this platform any more. Here is what remains. **What is produced when a signature closes** — All four pieces travel with the document. The key point is that they can be checked without logging into Code Contract. ## The signed document A PDF with the signatures drawn where you placed them, plus an invisible cryptographic signature which is what actually certifies the file has not been touched since. It opens in any PDF reader, and readers that can validate signatures will tell you whether the document is intact. ## The timestamp It certifies when it was signed, and an independent third party certifies it, not us. That is what stops the date being arguable: without a timestamp, a file's date is whatever the computer opening it says. ## The evidence chain This is the full account of what happened: when each notice went out and on which channel, when the link was opened, from what device the signing took place, whether there was an SMS code and when it was validated. It is what you produce when someone disputes a signature, and it is the difference between "I think they signed" and "they signed on 12 August at 10:14 from a mobile, after validating the code sent to their number". ## How an outsider checks it There is a public verification page: anyone holding the document can confirm it corresponds to a registered signature, without an account and without asking your permission. That is what you hand a lawyer, a bank or a court when they want to confirm it themselves. > [!NOTE] > Being independently verifiable is precisely the point. Evidence only its issuer can confirm is worth considerably less. ## Frequently asked questions **Do I have to stay a customer for the signature to hold?** No. The signed PDF carries the signature and seal inside: it validates in any reader without depending on us. Download it and keep it wherever you like. **What if someone modifies the PDF afterwards?** Validation fails and it is immediately obvious: the signature no longer matches the content. That is exactly what it is for. **Can I download just the certificate, without the contract?** Yes. The signature certificate is a separate, readable document summarising who signed and when. Handy for attaching to a file without sending the whole contract. **How long is it kept?** The document and its evidence are kept according to your organisation's retention policy. If you need it longer on your own terms, download it: the file is self-contained. **Does it work outside Spain?** The electronic signature framework is European, so the same reasoning applies across the EU. Outside it, it depends on each country's law. ## Ejemplos **Two years after signing, a former employee claims they never accepted the confidentiality clause.** - Downloads the signed PDF and its evidence chain - Confirms on the public verification page that the document is intact - Hands the lawyer the signature certificate with date, time and code validation → Evidence the other side's lawyer can verify independently, without having to take your word for it or ours. **Only the PDF is kept and the context is lost.** - Keeps the document with its evidence chain → The proof travels with the document. **A third party wants to verify the signature themselves.** - Points them to the verification page → They check without depending on your word. **The PDF is re-saved with another program and stops validating.** - Keeps the file exactly as it was signed → Validation still works years later. **The proof is needed for a procedure.** - Provides the signed document and its evidence → A complete item is submitted. **Nobody knows exactly what the proof contains.** - Reviews the fields in the evidence chain → You know what can be asserted and what cannot. --- --- id: KB-CO-005 url: https://app.codecontract.io/help/consigne/i-received-a-document-to-sign idioma: en categoria: consigne subcategoria: firmantes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-CO-002, KB-CO-006] citadoPor: [KB-CO-013, KB-CO-006, KB-CL-003, KB-CO-016, KB-TL-021, KB-GL-007] --- # I have received a document to sign _What that email is, whether it is legitimate, and what happens when you sign._ **Responde a:** i received a signing link is it safe · how do i sign a document sent to me · do i need an account to sign · can i sign from my phone Someone you deal with — your employer, a client, an accountant — has sent you a document to sign through Code Contract. If you were expecting that document, the link is the intended route; if you were not expecting it, write to whoever sent it before signing anything. That rule holds here and anywhere else. **En corto** - No account, no password, nothing to install. - Works on a phone exactly as on a computer. - You can read the whole document before deciding. ## What you are going to do 1. **Click the link in the email, SMS or WhatsApp.** 2. **Read the document. It is the full text, not a summary.** 3. **Confirm who you are if asked (usually a code sent to your phone).** 4. **Sign.** ## What happens next You receive a copy of the signed document. That copy carries the evidence inside it: when you opened it, from where, how you confirmed your identity and the moment you signed. That is what makes the signature hold up. > [!WARNING] > If the document says something you had not agreed, do not sign and say so. Signing is not a formality: once signed, the document stands. **Do I have to pay anything?** No. Signing never costs the signer anything. **Can I sign from my phone?** Yes, and most people do. **What if I do not want to sign?** You can decline. It is recorded, and the sender is notified. **Is my signature stored for other uses?** No. It applies to that document and nothing else. ## Ejemplos **You get a WhatsApp link to sign an amendment to your contract.** - Open the link on your phone - Read the amendment in full - Enter the code sent by SMS - Sign → The signed PDF arrives by email, with the exact time and the proof that it was you. **An email arrives to sign and it was not expected.** - Checks with the sender through another channel → Verification does not go through the email itself. **There is a fear that signing commits to something unread.** - Opens and reads the document before signing → You sign knowing what you are accepting. **The document has an error and is signed anyway.** - Flags it before signing and asks for a correction → Cancelling a signature afterwards is avoided. **It is signed from a phone in the middle of something else.** - Waits until it can be read properly → The signature is not given blind for convenience. **It is unclear who else has signed.** - Checks the status in the link itself → The full circuit is visible before deciding. --- --- id: KB-CO-006 url: https://app.codecontract.io/help/consigne/i-cannot-sign-what-now idioma: en categoria: consigne subcategoria: firmantes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-CO-005, KB-PR-001] citadoPor: [KB-CO-005, KB-CO-016, KB-PR-013, KB-GL-008] --- # I cannot get the signature to work _The code never arrives, the link expired, the document will not open: what to do in each case._ **Responde a:** the signing code never arrives · the signature link has expired · the document will not open · i lost the signing email Almost every problem when signing is one of these four, and all four are fixable without calling anyone. | What happens | Why | What to do | | --- | --- | --- | | The code never arrives | Poor signal, or the number is not yours | Request another code. If that fails too, tell the sender: they may hold the wrong number | | The link has expired | Links have a deadline | Ask the sender for a new one. It is immediate | | The document will not open | Slow connection or a very old browser | Try another browser, or mobile data | | I lost the email | Usually in spam | Search for the sender's name; failing that, ask them to resend | > [!NOTE] > Requesting another code invalidates nothing: the document is still waiting, and signing it a day later is worth exactly the same. ## What not to do - Sign on someone else's behalf, even if asked. The signature states who you are, and that is precisely its value. - Forward your link to a colleague so they can sign for you. Let them sign with their own. - Print, sign by hand and scan it back, unless asked to: it loses the evidence. **How many times can I request the code?** As many as you need, with a few seconds between attempts. **Can I sign without a phone?** It depends what the sender required. If they require a phone code, you need one. **What if the document has an error?** Do not sign it. Speak up: correcting and resending is faster than voiding a signature. ## Ejemplos **You are somewhere with no phone signal and the SMS code never arrives.** - Wait until you have wifi - Request another code → You sign that same evening; the document was still waiting. **The code does not reach the phone.** - Checks the registered number and asks for a resend → The blockage clears without changing the document. **The link has expired.** - Asks whoever sent it for a new one → The new link arrives in a minute. **The document will not open in the browser.** - Tries another browser or device → The problem is located before reporting it. **The signer is on a network that blocks the domain.** - Signs from another connection → The signature is resolved the same day. **The signature stalls halfway and it is unclear whether it counted.** - Checks the status before repeating → The same document is not signed twice. --- --- id: KB-CO-007 url: https://app.codecontract.io/help/consigne/signing-order-who-signs-first idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-008] citadoPor: [KB-CO-008, KB-CO-012] enLaApp: https://app.codecontract.io/consigne --- # Who signs first _When an order helps, when it gets in the way, and what happens if someone drops out._ **Responde a:** set a signing order · everyone signs at once · the second signer receives nothing · sequential signing multiple people When several people sign there are two ways to do it, and choosing wrong adds days for no gain. | Mode | When to use it | Cost | | --- | --- | --- | | All at once | Nobody depends on anybody: an agreement between equals | None. It is the fastest | | In order | One must see the previous signature, or an authorised signatory validates last | Each signer waits for the previous one | > [!IMPORTANT] > In order, if one person stalls everything stalls. The rest do not even know the document exists, because it never reached them. If there is no real reason for an order, do not set one. ## If someone drops out A signer can be replaced without redoing the send: the new one takes their position and the circuit continues. What was already signed stays signed. **Can I mix? Two at once, then a third.** Yes: signers are grouped by position, and within each position they go in parallel. **Does the last one see the earlier signatures?** Yes, and that is usually the reason for an order. **Can someone be skipped?** Yes, by removing them from the circuit. Who removed them and when is recorded. ## Ejemplos **A contract is signed by two partners and then validated by an authorised signatory.** - Puts both partners in position one, in parallel - The signatory in position two → The partners sign the same day and the signatory closes the next, already seeing both signatures. **An order is enforced and the first signer is on holiday.** - Removes the ordering if it is not needed → The others sign meanwhile. **One signature must follow another for good reason.** - Defines the order only at that point → The circuit reflects the real procedure. **A signer drops out of the circuit.** - Replaces them and continues from where it was → There is no need to start over. **Everyone signs at once and there is version confusion.** - Confirms everyone signs the same document → There is a single final copy. **Nobody knows whose turn it is.** - Checks the status per signer → The right person is chased. --- --- id: KB-CO-008 url: https://app.codecontract.io/help/consigne/cancelling-or-correcting-a-signature-request idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-007, KB-TZ-001, KB-CO-022] citadoPor: [KB-CO-007, KB-CO-011, KB-PR-008, KB-CL-015, KB-PR-024] enLaApp: https://app.codecontract.io/consigne --- # Cancelling or correcting a request _You sent the wrong document. What can be undone and what cannot._ **Responde a:** cancel a sent signature request · i sent the wrong document · correct a contract already sent for signature · void a signature request It happens. The document had a wrong figure, or it went to the wrong person. What matters is what can be undone, and that depends on whether anyone has signed. | State | What you can do | | --- | --- | | Nobody has signed | Void it and resend. The link stops working immediately | | Someone has signed | Void the circuit, but the existing signature does not vanish: it remains as a signature on a voided document | | Everyone has signed | The document is closed. Correct it with another document, not by deleting this one | > [!IMPORTANT] > A signature is never deleted. That is exactly what makes it worth something: if it could be made to disappear, it would prove nothing. A document signed in error is corrected with an amendment or a replacement. ## How to void 1. **Open the request in Consigne.** 2. **Click "Void".** 3. **Write the reason — signers see it and it stays on the record.** > [!NOTE] > Voiding notifies anyone who had not yet signed, which is what stops them signing a document that no longer stands. **Does the signer know it was voided?** Yes, they receive a notice with the reason you write. **Do I get the credit back?** A consumed send is not refunded; the corrected resend counts as a new one. **Can I change just one signer's email?** Yes, without voiding, as long as that person has not signed. ## Ejemplos **A contract goes out with the wrong start date and nobody has signed yet.** - Voids it stating "incorrect start date" - Fixes the document - Sends it again → Signers receive the correct one without ever having signed the wrong one. **The draft is sent instead of the final version.** - Cancels the send before anyone signs → No signature lands on the wrong document. **One of the three has already signed.** - Cancels and resends explaining why → The signer understands why it comes round again. **The document is already signed by everyone.** - Issues a correcting annex and sends it for signature → The correction is documented rather than hidden. **It is cancelled without telling the signers.** - Notifies whoever had already signed → Nobody is left holding a copy that no longer stands. **It is cancelled and the trace of what happened is lost.** - Keeps the record of the cancelled send → The history can be explained. --- --- id: KB-CO-009 url: https://app.codecontract.io/help/consigne/the-legal-standing-of-the-signature idioma: en categoria: consigne subcategoria: prueba audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-003, KB-TZ-001] citadoPor: [KB-CO-012, KB-CO-018, KB-CO-022, KB-GL-003, KB-GL-004, KB-GL-007] --- # What the signature is worth _What an electronic signature actually proves, and what it takes to defend it._ **Responde a:** is an electronic signature legally valid · what is a digital signature worth · does it hold up in court · simple vs qualified signature An electronic signature is not worth something because it is electronic: it is worth what it can prove. And what it can prove is three concrete things. **En corto** - Who signed — and what was used to check it was that person. - What they signed — the exact document, not a similar version. - When they signed — with a time you did not set yourself. ## All three, together Each one alone can be argued with. Together, not so: if the document carries a fingerprint no later change could match, the time is certified by a third party, and there is a record that the signer received a code on their phone and entered it, anyone disputing it has to explain how all of that happened without them. ## How much checking is right | What you are signing | Reasonable checking | | --- | --- | | An internal authorisation | Email. The signer is already identified by their account | | A contract with a third party | Code to their phone. Adds something only that person has | | A significant financial commitment | Phone code plus identity document | _More checking is more friction. The balance follows what is at stake, not habit._ > [!WARNING] > Some documents must by law be signed before a notary or with a qualified signature. No platform replaces that; if you are unsure about a specific document, ask your adviser first. **Is it valid outside Spain?** The European framework (eIDAS) recognises electronic signatures across the EU. Outside, it depends on the country. **What if the signer denies it was them?** That is what the evidence is for: time, device, code received on their number. **Do I need to keep the PDF?** You can, but the copy with the evidence lives on the platform and can be verified without it. ## Ejemplos **A supplier denies having accepted a contract term two years later.** - The signed document is retrieved - Fingerprint, certified time and the record of the code sent to their phone are checked → The argument ends without lawyers: what is on record admits only one reading. **A signer denies having signed.** - Opens the evidence chain → The code, the device and the time are on record. **There is a question whether it counts as much as a paper signature.** - Compares what is recorded in each case → It becomes clear that on paper the time is almost never recorded. **The signature must be defended before a third party.** - Provides the document with its evidence → The third party verifies for themselves. **A sensitive document was signed at a low level.** - Reviews the level criteria by document type → The level matches the risk from the start. **Only a screenshot was kept.** - Keeps the original signed document → The proof is the file rather than an image. --- --- id: KB-CO-010 url: https://app.codecontract.io/help/consigne/signature-reminders-how-often idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-001, KB-TL-004] citadoPor: [KB-CO-014, KB-CO-019] enLaApp: https://app.codecontract.io/consigne --- # Reminders: how often to chase _Where reminding helps and where it starts to annoy, with numbers._ **Responde a:** how often to send signature reminders · set up automatic reminders · the signer will not sign what do i do · stop sending reminders A well-placed reminder closes signatures. Four in a row get you marked as spam, and then none of them arrive. **En corto** - The first at day three. Sooner is pushy; later they have forgotten. - Three in total at most, well spaced. - Past the third, the problem is not memory: it is something else. ## A rhythm that works | When | What goes out | Why | | --- | --- | --- | | Day 0 | The request | — | | Day 3 | Gentle reminder | Most people sign here | | Day 7 | Reminder with a deadline | Gives a reason to do it today | | Day 12 | Final notice | And then, a phone call | > [!NOTE] > If they have not signed after twelve days, what is missing is not a reminder: either they disagree with something, or the document is not reaching them, or the right person is someone else. All three are solved by talking, not chasing. ## Changing channel beats repeating The fourth email lands in the same inbox as the previous three. An SMS lands somewhere else, and gets seen. **Can they be scheduled automatically?** Yes, you set the rhythm when sending and they go out on their own. **Do they stop once the person signs?** Yes, immediately. **Can I stop them halfway?** Yes, at any point. ## Ejemplos **A company sends forty employment amendments and wants them closed in two weeks.** - Schedules reminders at days 3, 7 and 12 - On day 8 phones the five still outstanding → Thirty-five sign on their own; the remaining five are sorted by phone in an afternoon. **Reminders go out daily and the signer stops reading them.** - Spaces the reminders out → The nudge works again. **There are no reminders and the document is forgotten.** - Turns on automatic reminders → The signature arrives without anyone chasing by hand. **Reminders reach somebody who already signed.** - Checks the reminder excludes those who signed → Nobody gets notices that are not theirs. **The reminder does not say when it is needed by.** - Includes the deadline in the notice → The signer prioritises sensibly. **After several reminders it is still unsigned.** - Changes channel and records it → Follow-up does not stay stuck in email. --- --- id: KB-CO-011 url: https://app.codecontract.io/help/consigne/preparing-a-document-for-signature idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-008, KB-CO-017] citadoPor: [KB-PR-008, KB-CO-015] enLaApp: https://app.codecontract.io/consigne --- # Preparing a document for signature properly _Where each signature goes, what each person fills in, and why checking first saves voiding later._ **Responde a:** place the signature field in the pdf · have the signer fill in a field · prepare a contract for signing · signature and date fields Almost every request that has to be voided did not fail at signing: it failed at preparation. Five minutes of checking beforehand avoids the awkward conversation afterwards. **En corto** - Each signer has their own spot: two signatures in one place collide. - Anything the signer must fill in should be their field, not a blank space. - The system sets the date; do not leave it to be written by hand. ## The four kinds of field | Field | Filled by | When to use it | | --- | --- | --- | | Signature | The signer | Always, one per person | | Date | The system | Never by hand: a date written by the signer does not prove when they signed | | Signer's detail | The signer | ID number, job title, an account number you do not hold | | Your detail | You, when preparing | Amount, reference, anything you already know | ## The five-minute check 1. **Confirm there are as many signature fields as signers, each in its own place.** 2. **Read the document through once, not diagonally. Wrong amounts show up here.** 3. **Look at the preview exactly as the signer will see it.** 4. **If it is more than twenty sends, send one to yourself first.** > [!IMPORTANT] > A document with the wrong amount signed by two hundred people is not fixed by voiding: it has to be resent with an explanation. The five minutes beforehand are worth more than any feature afterwards. > [!WARNING] > Do not add fields the signer cannot complete. Asking for a detail they do not have to hand is the surest way to have them abandon the document. **Can I move a field after sending?** If nobody has signed, yes, by resending. After that, no. **Can it be signed on more than one page?** Yes, as many times as you place signature fields. **What about annexes?** The whole thing is signed; annexes go inside the same document. ## Ejemplos **A company is about to send 180 amendments with a personalised amount.** - Sends one to themselves first - Checks the amount renders correctly and the signature sits where it should - Sends all 180 → None have to be voided, unlike the previous round where 180 were voided over one misplaced field. **It is sent without placing the signature fields.** - Places them before sending → The signer knows where to sign without asking. **Two signers sign in the same place.** - Assigns a field to each → Each signature is identified. **The signer needs to fill in a value.** - Adds the corresponding field → The value arrives with the signature rather than in a separate email. **The document has a typo that shows up at signing.** - Reviews it fully before sending → Cancelling and resending is avoided. **The PDF has blank pages at the end.** - Cleans the document before sending → The signer does not wonder whether something is missing. --- --- id: KB-CO-012 url: https://app.codecontract.io/help/consigne/who-should-sign-for-a-company idioma: en categoria: consigne subcategoria: firmantes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-007, KB-CO-009] citadoPor: [KB-LE-005, KB-CS-009] --- # Who should sign for a company _Signing without authority is the costliest mistake, and it does not show until it matters._ **Responde a:** who can sign on behalf of a company · authorised signatory contract · the signer had no authority · verify signing authority Someone from a company signing does not mean the company is bound. If the signer lacks authority for that act, the document may not hold — and you find that out exactly when you need it, not before. **En corto** - A job title is not enough: they need authority for that kind of act. - Authority has limits by amount and by subject matter. - Checking once, when onboarding the company, covers every contract that follows. ## Who usually can | Who | Normally | | --- | --- | | Sole or joint company director | Yes, broadly | | Authorised signatory | Yes, within what their authority says | | A managing director without authority | No, however it looks | | A department head | Only if they hold authority for it | _This is indicative: what governs is that company's actual power of attorney._ ## How to check without going mad 1. **Ask once, when onboarding the company: the power of attorney or a registry certificate.** 2. **Note who can sign what, and up to what amount.** 3. **On each contract, check against that note rather than asking again.** > [!IMPORTANT] > If the amount exceeds what the authority covers, someone who does hold it must sign. A contract signed beyond authority is exactly the one that gets disputed later. > [!WARNING] > Authority gets revoked. What was valid three years ago may not be today, and on an important deal a recent certificate is worth asking for. > [!NOTE] > Adding an authority check to supplier or client onboarding turns this into a one-off step instead of a doubt on every contract. **Can two people sign jointly?** Yes, by making both mandatory signers. **What if the wrong person signed?** The document can be challenged. Better to redo it with the right person. **Is this legal advice?** No. It is the practical criterion; the specifics come from your adviser. ## Ejemplos **A company discovers three significant contracts were signed by a director without authority.** - Starts requesting authority documents at client onboarding - Redoes the three with the correct signatory → Later contracts are signed by someone who can, checked in thirty seconds. **Somebody without authority signs.** - Checks who may sign before sending → The signature holds up the day it is reviewed. **Nobody knows who the supplier's authorised signatory is.** - Asks while preparing the send → The document goes to the right person first time. **The signatory changed and nobody said so.** - Reviews authority at renewals → The record stays current without surprises. **An employee signs out of convenience.** - Redirects to the signer with authority → A questionable signature is avoided. **Authority must be evidenced to a third party.** - Keeps the authority documentation with the contract → Everything is provided together when asked. --- --- id: KB-CO-015 url: https://app.codecontract.io/help/consigne/your-first-signature-request idioma: en categoria: consigne subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-011, KB-CO-013, KB-PS-007] citadoPor: [KB-CS-011, KB-CS-014, KB-CO-019] enLaApp: https://app.codecontract.io/consigne --- # Your first signature request _From a PDF on your computer to a signed document, the first time._ **Responde a:** how do i send a document for signature · send a contract for electronic signature · first time using consigne · how signing a pdf works Take a real document you have to sign anyway. The five minutes this first time are the same five you were about to spend printing it, and from here on nothing gets printed. ## The five steps 1. **Upload the document** — The PDF as it is. No special preparation needed. 2. **Say who signs** — Name and email. If there are several, decide whether they sign at once or in order — at once is faster and usually right. 3. **Place each signature** — One field per person. Two signatures in one spot collide. 4. **Choose how identity is checked** — Email is enough internally; a phone code for a third party. 5. **Send** — They get a link. No account, nothing to install, and it works on a phone. ## Five minutes before hitting send - Read the document through once. Wrong amounts show up here and not later. - Check there are as many signature fields as signers. - Look at the preview exactly as the recipient will see it. > [!IMPORTANT] > If you are sending the same document to more than twenty people, send it to yourself first. A misplaced field across two hundred sends is two hundred awkward conversations, and they cannot be pulled back out of anyone's inbox. ## What happens next You will see whether it arrived, whether it was opened and when they signed. When it finishes, everyone receives a copy with the evidence inside: when it was opened, how identity was checked, and the exact moment of signing. That is what makes it hold. > [!NOTE] > The date is set by the system, never by hand. A date written by the signer does not prove when they signed, which is precisely what has to be provable. **Is it legally valid?** Yes, and with more evidence behind it than a hand-signed sheet, where nobody records the time. **Does it cost the signer anything?** No, never. **What if I get it wrong?** As long as nobody has signed, void it and send the corrected version. ## Ejemplos **A company prints, signs and scans every tenancy agreement.** - Sends the next one through Consigne - The tenant signs from their phone that afternoon → The agreement is signed the same day and with a certified time, which the paper never had. **The perfect document is prepared before testing.** - Sends any PDF to a colleague → The whole circuit is seen in ten minutes. **Nobody knows what the signer receives.** - Adds themselves as a signer → You know the other side before using it with anyone. **It is tested with a real, confidential document.** - Uses a test document → Learning compromises nothing. **It is signed and nobody knows where the result goes.** - Checks where the signed document is stored → You know where to look next time. **The first time is slow and discouraging.** - Saves the setup that worked → The second send takes a minute. --- --- id: KB-CO-016 url: https://app.codecontract.io/help/consigne/signing-from-a-phone-anywhere idioma: en categoria: consigne subcategoria: firmantes audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-006, KB-CO-005] citadoPor: [KB-CO-003] --- # Signing from a phone anywhere _On a site, in a lorry or at a client's home. What you need and what you do not._ **Responde a:** signing from a phone · can you sign without a computer · signing on site without a printer · signing a document on mobile step by step Most delayed signatures are not delayed by doubts about the document: they are delayed because the person is not at a computer when it arrives, and by the time they are, they have forgotten. ## What you need | You need | You do not need | | --- | --- | | The link that was sent | To install any app | | A connection, mobile data is fine | An account on the platform | | To be able to read the document | A printer or scanner | | And sometimes a verification code | A digital certificate, unless required | > [!IMPORTANT] > The right-hand column surprises signers most. Many people set the email aside thinking "this needs the office computer", and it does not: you open it, read it and sign with a finger. ## What the journey looks like 1. **Open the link** — It goes straight to the document, with no sign-up or password. 2. **Read it** — Worth doing properly: it is what you are signing. 3. **Verify who you are, if asked** — A code arriving separately, to prove it is you. 4. **And sign** — With a finger or by accepting; a copy and evidence remain. > [!WARNING] > If the document is long and complex, signing on a phone between two other things is not a good idea even though you can. The convenience of signing anywhere does not change what you are taking on by signing. ## When there is no signal In a basement site or a warehouse with no coverage, the link will not open. What works is preparing it beforehand or signing on the way out; what does not work is going back to paper "just for today", because that paper is the one nobody scans afterwards. **En corto** - The link is still valid later: it is not lost by not opening it immediately. - If it is forgotten, a reminder will arrive. - And if the link has expired, another can be requested. > [!NOTE] > Signing costs the signer nothing. Consumption is on the sender's side, and a signature made on a phone is worth exactly the same as one made on a computer. **Is a finger signature valid?** Yes. The value comes from the evidence around it, not the stroke. **Do I get a copy?** Yes, when it completes. **What if I sign by mistake?** Tell the sender: they can void it and send again. ## Ejemplos **A site manager takes days to sign because he only opens email at the office.** - Opens the link from his phone on site - Signs with a finger after reading it → Reports and amendments stop piling up and get signed the day they arrive. **The signer is on site with no computer.** - Signs from the phone's browser → The signature does not wait for a return to the office. **The signer is driving and cannot stop for long.** - Opens the link and signs during a stop → The process completes without travel. **The document does not read well on a small screen.** - Checks how it looks before sending → The signer reads what they sign. **The code arrives on the same phone used to sign.** - Signs anyway: the code works on the same device → No second device is needed. **Signal is poor and the signature cuts out.** - Retries when the connection is stable → The signature completes without duplicating the document. --- --- id: KB-CO-017 url: https://app.codecontract.io/help/consigne/documents-that-must-be-signed-every-year idioma: en categoria: consigne subcategoria: enviar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-014, KB-CF-012] citadoPor: [KB-CO-011] --- # Documents that must be signed every year _Renewals, codes of conduct and annexes: what repeats is best repeated by itself._ **Responde a:** signatures that repeat every year · renewing acceptance of a code of conduct · sending the same document for signature annually · annual signature campaign Some documents are not signed once: they are signed every year. Codes of conduct, internal policies, confidentiality clauses, collaboration terms, authorisations that expire. And because they come round once a year, they always catch someone on holiday. ## How to run the annual campaign 1. **A list of who must sign this year** — Not last year's: people change, and that lag is the number one cause of gaps. 2. **A single send to everyone** — The same document to two hundred people counts as one action, not two hundred. 3. **Automatic, spaced chasing** — Most sign within 48 hours; the rest with reminders. 4. **And a visible list of who is missing** — It enables a targeted final push instead of an email to everybody. > [!IMPORTANT] > Keep each year's signed version, not just the latest. If the document changes — and it usually does — what that person accepted was that year's text, and that is what you must be able to show if it is ever disputed. ## The three usual gaps | Gap | Why it happens | How to close it | | --- | --- | --- | | Someone who joined after the campaign | The list was January's and they arrived in March | Include it in onboarding, do not wait a year | | Someone on leave or holiday | They missed the send and nobody reviewed after | The outstanding list when the campaign closes | | Someone who changed role | A different document applied to them | Review the list by role, not the whole headcount | > [!WARNING] > The first is the commonest and looks worst in an audit: half the workforce with the policy signed and a cluster of people without it because they joined in the wrong month. If onboarding includes whatever applies, it stops happening. ## When to run it in waves **En corto** - Over two hundred people, so the review stays manageable. - With several languages, to send each version to the right people. - And when the document differs by group, so texts do not get mixed. > [!NOTE] > Scheduling the send for a specific time helps more than it seems: Monday morning gets noticeably better response than Friday afternoon, and that is decided when scheduling, not when sending. **What about someone who never signs?** By the third reminder it stops being chasing and becomes a company decision. **Can we tell who read it?** You can see who opened it and who signed, with date and time. **Does it work for suppliers?** Yes, it is the same mechanism as annual documentation renewal. ## Ejemplos **A company sends its code of conduct every January and gaps always remain.** - Builds the current year's list, not last year's - Adds the document to onboarding for later joiners → The campaign closes at 100% and nobody is left unsigned because of their start month. **The annual renewal happens whenever somebody remembers.** - Schedules the send in advance → It goes out by itself each year. **It is sent to a hundred people one by one.** - Launches the same document to everyone at once → The campaign is prepared in an afternoon. **It is renewed with somebody who already signed this year.** - Excludes those with a current signature → Nobody signs the same thing twice. **Nobody knows who is still to sign.** - Checks the campaign's progress → Only those outstanding are chased. **The document changes from one year to the next.** - Keeps each version with its year → You know what each person signed and when. --- --- id: KB-CO-018 url: https://app.codecontract.io/help/consigne/if-someone-denies-having-signed idioma: en categoria: consigne subcategoria: prueba audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-004, KB-CO-009] citadoPor: [KB-CO-020] --- # If someone denies having signed _What holds an electronic signature up is not the signature: it is everything recorded around it._ **Responde a:** a client says they did not sign · challenging an electronic signature · how do I prove that person signed · what if they deny the signature It is rare, and when it happens it is usually months later and over something else: someone disputes an invoice, an order or a term, and along the way says they never signed that document. The question then is not whether the signature is valid in the abstract, but what you can show. ## What you show, and what each piece proves | What was recorded | What it proves | What it does not prove | | --- | --- | --- | | The document and its fingerprint | That it has not been altered since | Who signed it | | The exact moment, timestamped | When it happened, without relying on your clock | That the person agreed | | The address or number it went to | Who it was aimed at | That this person, and not another, read it | | The one-time code, if used | That whoever signed had access to that mailbox or phone | The person's legal identity | | The trail: sent, opened, signed | That there was a voluntary act, with its trace | The intention behind it | > [!IMPORTANT] > No single row of that table proves everything on its own, and that is the part almost nobody expects: **what convinces is the whole set**. An electronic signature is not defended by showing «the signature», but by showing the full sequence — who it went to, where it was opened from, which code was used, when, and over which exact document. That is why sending documents around by hand on the side matters so much: the missing piece is always the one they ask about. ## What to do when the denial arrives 1. **Redo nothing** — Do not resend, do not re-sign «to have it cleaner». That muddies what you already hold. 2. **Download the complete set as it stands** — Document, evidence and timestamp, unedited and unassembled. 3. **Cross-check against what sits outside** — Emails, orders, deliveries: they nearly always back the same version. 4. **And pass it to your adviser before replying** — The legal answer shapes what you say from the first line. > [!WARNING] > The commonest case is not bad faith: it is **that someone else with access to the mailbox signed** — a colleague, someone in admin, whoever runs the generic address. It is usually true and usually irrelevant to validity, but it changes the conversation. If the document matters, send it to a named person rather than to `info@`, and require a code; not out of distrust, but so there is something to show afterwards. ## What raises the bar before it happens **En corto** - Send to a person's name and address, not to a shared mailbox. - Require a one-time code on anything with consequences. - And use a qualified signature when the document warrants it: it changes who has to prove what. > [!NOTE] > Which signature level suits each document, and how it is weighed in proceedings, depends on the framework that applies to you — **eIDAS** in Europe, among others — and on the type of contract. **Your adviser decides that**; here we explain what is worth keeping so that decision does not arrive too late. **Is it worth less for being electronic?** That is not the question: what counts is the evidence around it. **What if it was signed five years ago?** It still works if you kept it complete; the timestamp is what fixes the «when». **Can I add evidence now?** No: anything produced today is dated today, and it shows. ## Ejemplos **A client disputes an order and says they never signed the acceptance note.** - Downloads the complete set untouched and passes it to their adviser → The sequence shows who it went to, where it was opened from and which code signed it. **The signer says they never received the document.** - Checks the send and open evidence → It is on record when it was delivered and where it was opened. **They say somebody else signed for them.** - Checks the code sent and the device → The signature points to a device and a time. **Only the PDF is provided, without the evidence.** - Provides the document with its complete chain → The defence does not rest on an assertion. **The file was re-saved and no longer validates.** - Keeps the original exactly as signed → Verification still works. **A third party is asked to check it.** - Points them to the verification page → They check without intermediaries. --- --- id: KB-CO-019 url: https://app.codecontract.io/help/consigne/how-long-signing-really-takes idioma: en categoria: consigne subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-010, KB-CO-015] citadoPor: [KB-PS-007] --- # How long signing really takes _Signing takes a minute. Getting someone to sign takes as long as they take to open the email, which is not a technical problem._ **Responde a:** how long does an electronic signature take · waiting two days for a signature · how to speed up getting signed · the client is not signing what do I do The question always comes before the first send, and usually carries an expectation that is either too optimistic or too gloomy. The honest answer has two very different parts: the act of signing is instant; what takes time is everything else. ## Where the time actually goes | Stage | How long it tends to take | What it depends on | | --- | --- | --- | | Preparing and sending | Minutes | You | | Them opening it | Minutes to days | Their day, not the tool | | Signing once opened | A minute | Whether it is clear what to do | | With several signers | As long as the slowest | How the order is arranged | | If someone must check it first | Days | Who else has to see it inside their company | > [!IMPORTANT] > The surprising row is the last, and it explains most long waits: **the person receiving it often cannot decide alone**. They need their manager, their adviser or their department to look at it, and that step is invisible from outside — to you it looks like they never opened it. Asking «does anyone else need to see this first?» when you send saves more days than any reminder, because it turns chasing into helping. ## What actually shortens the wait **En corto** - Send to the person who can sign, not to whoever passed you the contact. - Say in the message what it is and how long it takes: doubt weighs more than laziness. - Make it signable from a phone with nothing to install. - And do not send five documents at once when one moves things along. > [!WARNING] > A calendar detail almost nobody accounts for: **what goes out on Friday afternoon gets signed on Monday or Tuesday**. Not from indifference, but because Friday's email is read on Monday with forty others in front of it. If your date is tight, the day you send matters nearly as much as the reminder, and Tuesday morning outperforms any later chasing. ## When it is worth worrying 1. **If it has not been opened in two days** — It is usually the email, not the person: check the address. 2. **If it was opened and not signed** — There is a doubt or a missing approver: a short call settles it. 3. **If the turn is stuck on the second signer** — Check whether the first one told them, or nobody did. > [!NOTE] > Signing speed is not decided by the technology: it is decided by how easy it is to understand what is being signed and who has to see it first. Everything else is minutes. **How many reminders are worth sending?** Few and spaced out; past the third they stop working. **Is signing from a phone slower?** The opposite: it is what shortens the wait most. **Can I tell whether they opened it?** Yes, and that is exactly what tells you whether the problem is the email or the decision. ## Ejemplos **A company waits four days for a signature and assumes the client is not interested.** - Asks whether anyone else must see it first and sends to the person who decides → It is signed that afternoon: the delay was an internal review nobody had mentioned. **Time is measured from when the document is opened.** - Counts from when it is sent → The figure reflects the real wait. **It is sent Friday afternoon and counted as a delay.** - Schedules sends within working hours → The figure stops penalising the signer. **One particular signer always takes weeks.** - Talks to them or changes contact → The cause is addressed rather than the average. **Times are compared across very different documents.** - Separates by document type → The comparison makes sense. **It is measured and nothing changes.** - Adjusts reminders using the figure → The indicator supports a decision. --- --- id: KB-CO-020 url: https://app.codecontract.io/help/consigne/when-a-signer-asks-for-their-copy-years-later idioma: en categoria: consigne subcategoria: prueba audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-004, KB-SC-008, KB-CO-018] citadoPor: [KB-CO-021] --- # When a signer asks for their copy years later _They lost the email, changed jobs or simply need it. What to send, and why it should match yours exactly._ **Responde a:** a signer asks me for the signed document · resending a signed copy years later · the client lost the signed contract · can I resend what was signed An email arrives from someone who signed something with you three years ago asking for their copy. It is a reasonable and frequent request, and how you answer says a good deal about how tidy your archive is. ## What you send them | Piece | Send it? | Why | | --- | --- | --- | | The signed document | Yes | It is what they ask for and what is theirs | | The signature evidence | Yes, if asked or if they will use it as proof | Without it, it is just another PDF | | The whole file it sat in | No | It may contain third parties' or your own material | | Other signers' documents | Only what concerns them | Each is entitled to their own | > [!IMPORTANT] > Before resending, one detail is worth understanding: **what you send must be the same file, not a reprint**. If you open the document and save it again, or export it from another program to shrink it, it stops matching the original — and the day they take it to someone who checks it, that check will fail. Not because you changed the content, but because it is no longer the same file. It goes back exactly as stored. ## Two checks before sending 1. **That whoever asks is who signed** — An email with their name is not enough if the address differs. 2. **And that it goes to an address of theirs** — Not to the company where they no longer work. 3. **Then resend the original file and its evidence** — No conversion, no recompressing the content, no touch-ups. > [!WARNING] > The awkward case: **whoever asks is no longer at the company that signed**. They did sign, but on behalf of another party: the document belongs to the company, not to them personally. The prudent move is to send it to the company, or to ask first — and if they press, treat it as what it is, a request about a third party's documentation. Exactly the kind of decision worth settling once with your adviser and applying consistently. ## What makes this a minute rather than an afternoon **En corto** - That the signed document lives in the file, not only in the sender's inbox. - That the evidence was stored beside the document, not somewhere else. - And that it can be found by the signer's name, not only by date. > [!NOTE] > If what was signed contains third parties' personal data, sending it whole may not be right. **How that is resolved in your case is for your adviser**; the point here is not to resend by reflex without looking at what is inside. **Can we charge for resending it?** That is your call, though it rarely justifies the conversation. **What if we no longer have it?** Say so plainly and explain how long it was kept. **Is a screenshot or a printout enough?** For reading yes; as evidence no: that can no longer be checked. ## Ejemplos **A client asks for a contract signed three years ago and gets a re-exported version.** - Resends the original file exactly as stored, with its evidence → The copy they receive can be verified, which is precisely what they need it for. **A signer asks for their copy three years later.** - Sends them the signed document with its evidence → They receive the same thing you hold. **A copy is sent without the evidence.** - Sends the original signed file → Both parties hold the same proof. **They no longer work at the company that signed.** - Checks who is entitled to receive it → It goes to whoever has the right. **Every copy request means a search.** - Keeps signed documents organised by file → Delivery is immediate. **Their copy does not match yours.** - Compare the document's fingerprint → Which one is good is settled in seconds. --- --- id: KB-CO-021 url: https://app.codecontract.io/help/consigne/ive-signed-do-i-get-a-copy idioma: en categoria: consigne audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-004, KB-CO-020] citadoPor: [KB-CO-001] --- # I've signed — do I get a copy? _Yes, and it is worth keeping your own: alongside the document comes the evidence of when and how it was signed._ **Responde a:** do i get a copy of the signed document · where do i download what i signed · i signed and dont have the document · how do i get the signed pdf **Yes, you get a copy, and you should keep your own in your own files.** Trusting that whoever sent it will have it is not enough: those are their files, not yours, and in three years that company may no longer exist or the person handling it may have left. ## What to keep — and it is not only the document | What | What it is for | | --- | --- | | The signed document | It says what you agreed | | **The signature evidence** | **It says who signed, when and how** | | The email it came with | It sets the context if doubts ever arise | > [!IMPORTANT] > **Keep both together, in the same folder, from day one.** A signed document without its evidence is a PDF with a name typed on it: if someone disputes the signature, what answers that dispute is the record of how it was made, not the document. It is precisely the part people do not download because it does not look important, and the only one needed on the day it matters. ## If you cannot find it 1. **Look for the email from when signing finished** — Usually the shortest route, and it is in your inbox. 2. **Try the original link** — While it is still live, it can sometimes be downloaded again. 3. **And failing that, ask whoever sent it to you** — They have it, and it is not an odd request: it happens daily. > [!WARNING] > An oversight with consequences years later: **keeping it only on your phone or in the downloads folder**. That document survives a change of handset less often than you would think, and it is exactly the one you will be asked for when you no longer remember who you signed with. Two minutes moving it to where you keep important things is worth more than anything else you do with it today. **Do I have to register to download it?** No. It downloads from the link or arrives by email. **What if I lose the email?** Ask whoever sent it to sign: they keep it. **Is a screenshot enough?** To remember, yes. As evidence, no: download the document. ## Ejemplos **Someone signs on their phone and leaves the document in the handset's downloads folder.** - Moves it the same day to where they keep important things, along with the signature evidence → The document survives the next change of phone. **Two years later a clause is disputed and only the PDF turns up, with no evidence.** - Asks whoever sent it for the record of how the signature was made → The dispute closes on who signed and when, not on a loose PDF. **It is signed and closed without downloading anything.** - Saves the copy that arrives after signing → Your own record depends on nobody else. **Only a screenshot of the signing screen is kept.** - Keeps the complete signed file → The proof is the document rather than an image. **The copy is kept in a personal mailbox.** - Keeps it where the team can see it → It is not lost when people change. **The copy is requested months later from whoever sent it.** - Saves the copy at the moment of signing → No favours have to be asked later. --- --- id: KB-CO-022 url: https://app.codecontract.io/help/consigne/asked-to-sign-something-i-dont-understand idioma: en categoria: consigne audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-003, KB-CO-009] citadoPor: [KB-CO-008] --- # Asked to sign something I don't understand _Don't sign. Asking first is normal and delays nothing; undoing a signature afterwards is another matter._ **Responde a:** asked to sign a document i dont understand · can i ask for time before signing · what happens if i sign without reading · i dont understand what im signing **Don't sign yet.** Asking what it is and what it is for is a normal request answered in a minute; a signature already given is far harder to argue with afterwards, because what you sign is presumed read. ## The three questions that clear up nearly everything 1. **What exactly am I confirming?** — That I received something, that I agree, or that I commit to something. Three very different things. 2. **What does it commit me to, and until when?** — A term, an automatic renewal or a penalty changes the decision. 3. **Why am I the one being asked?** — Sometimes the answer reveals that someone else should have signed. > [!IMPORTANT] > **Asking for time does not make you look bad.** «Give me until tomorrow, I want to read it» is a sentence everybody hears every day and nobody reads as distrust. What does raise eyebrows is signing five pages in thirty seconds: the sender does not always welcome it — sometimes it means you never opened it, and that is a problem for both of you. ## Signs it deserves a slower look **En corto** - There is a lot of urgency with no apparent reason for it. - It is longer than the matter warrants. - It renews itself, or mentions terms nobody had told you about. - Or you do not understand it after reading it twice — which is reason enough on its own. > [!WARNING] > A confusion worth undoing because it reassures a lot of people: **signing from your phone does not change the weight of what you sign**. The convenience of two taps makes it feel like something minor, and it is not: it binds exactly as if you had signed with a pen at a notary's. The convenience is in the process, never in the consequences. > [!NOTE] > What your signature means on a specific document, what it commits you to and what room remains afterwards depends on the content and the type of document. **If what you are asked to sign carries significant consequences, your adviser looks at it first**; here we explain why asking beforehand is always cheaper than fixing it after. **Can I ask them to explain it?** Yes, and it is the most normal thing in the world. It takes a minute. **Can I sign only part of it?** No: the whole document is signed. If something is wrong, ask for it to be changed first. **I already signed and did not understand it** Say so as soon as possible, in writing. The later, the harder. ## Ejemplos **A five-page document arrives urgently and gets signed on the spot so as not to look difficult.** - Asks for a day and puts the three questions before signing → An automatic renewal nobody had mentioned comes to light. **The document was meant for the director and reaches someone else.** - Asks why they are the one being asked, before signing → The recipient is corrected and the signature comes from whoever can give it. **It is signed to avoid seeming difficult.** - Asks before signing → Asking costs a minute; undoing a signature costs far more. **The document has a clause that is not understood.** - Asks for it to be explained in writing → The explanation is recorded alongside the document. **A document that does not concern their company is signed.** - Says so before signing → An ineffective signature and a correction are avoided. **There is pressure and it is signed unread.** - Asks for a reasonable window to review it → Haste stops being the criterion. --- --- id: KB-SC-001 url: https://app.codecontract.io/help/smartcheck/certifying-a-piece-of-evidence idioma: en categoria: smartcheck subcategoria: empezar modulo: smartcheck audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-001, KB-PS-002, KB-SC-002, KB-SC-003, KB-PS-018] citadoPor: [KB-PS-001, KB-CO-004, KB-SC-002, KB-SC-003, KB-SC-004, KB-CS-001, KB-CS-002, KB-CR-001, KB-IN-001, KB-TZ-002] enLaApp: https://app.codecontract.io/smartcheck --- # What SmartCheck is and how to certify a piece of evidence _Upload something and it is sealed with a demonstrable, immutable date, ready for when you are asked._ **Responde a:** how do I prove I had a document on a given date · give a document a trusted date · certify a document for an audit · what is SmartCheck · document timestamping SmartCheck exists for one very specific moment: the day someone — an inspector, a lawyer, a client, an auditor — says "prove to me you had this on date X". It asks nobody for anything and cross-checks nothing: it certifies and archives. **En corto** - It is for proving a document existed, exactly as it is, on a specific date. - Sealing is immediate: there is no overnight process to wait for. - You can also certify loose data, with no file behind it. - Certified items cannot be edited or deleted — that is the function, not a limitation. - SmartCheck does not read documents with AI: it seals them exactly as they arrive. ## What problem it actually solves The date on a file on your computer proves nothing: anyone can change it. An email with the document attached proves a little more, but it sits in your inbox and you control it. What you need when someone is going to be held to account is for a third party to be able to check the date without trusting either side. That is what SmartCheck does: it computes a unique fingerprint of the document, seals it with a timestamp, and records it in a way that makes any later alteration instantly detectable. **What happens when you certify** — The whole process happens in seconds, at upload time. The fingerprint is what makes it demonstrable that the file has not changed. ## How to certify a document 1. **Go to SmartCheck and create a folder** — For example "2026 audit". Organising by whatever criterion you will be asked about — quarter, site, client — saves time the day the request arrives. 2. **Click "Upload" and drop the file** — Any format: PDF, photo, spreadsheet, video, audio. It does not have to be a "formal" document. 3. **Wait a couple of seconds** — As soon as it uploads, its fingerprint is computed and sealed. There is no extra step to remember. 4. **Check it shows as certified** — The file is marked with the exact date and time of sealing. That is what counts as evidence. ## Certifying data with no document Not everything worth dating is a file. A sensor reading, a committee decision, a statement, a stock count: you fill in a form and it takes exactly the same path — fingerprint, seal and date — with no need to manufacture a PDF just to have something to upload. ## How it differs from the other two modules | What to look at | SmartCheck | Trackline | Consigne | | --- | --- | --- | --- | | Who acts | Only you | Someone else delivers to you | Someone else signs | | Does it read the content? | No, it seals it as is | Yes, it extracts data with AI | No | | What it produces | A dated piece of evidence | A complete case file | A signed PDF | | What it is for | Proving it existed | Gathering what is missing | Proving an agreement | > [!NOTE] > SmartCheck not reading the document is deliberate. Nothing is interpreted here: what you uploaded is frozen exactly as it was. ## Frequently asked questions **Which formats does it accept?** Any. Certification works on the file as a sequence of bytes, so a video or an audio file is sealed just like a PDF. **How long does certification take?** Seconds, at upload time. No overnight jobs, no queues to wait for. **Can I certify something that is already in another module?** The modules are independent and each keeps its own. If you want a document certified in SmartCheck, upload it to SmartCheck. **What if the document changes in a month?** You certify the new version. Both remain, each with its own date, and that sequence is usually exactly what is worth proving. **Can certification be automated from another system?** Yes, there is a public API: an ERP or a quality system can certify each invoice or each record at the moment it is generated, without anyone having to remember. ## Ejemplos **An ISO 9001 company runs internal audits every quarter and always ends up arguing whether a record was made before or after the non-conformity.** - Creates one folder per quarter - Certifies each record the same day it is produced - Shares the evidence link with the auditor → The auditor checks the date of each record independently, without having to take anyone's word for it. **Proof is needed that a report existed on a given date.** - Timestamps the report the day it is closed → The date does not rest on anyone's word. **The file's modified date is relied upon.** - Timestamps the document instead of trusting the system → The date stops changing when the file is copied. **Something is sealed and then corrected.** - Seals the corrected version too → Both versions carry their own date. **You want to seal without revealing the content.** - Shares only the document's fingerprint → The proof travels without the content. **Nobody knows what has been sealed and when.** - Checks the evidence listing → The history is in plain view. --- --- id: KB-SC-002 url: https://app.codecontract.io/help/smartcheck/why-it-cannot-be-edited-or-deleted idioma: en categoria: smartcheck subcategoria: certificar modulo: smartcheck audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-SC-001, KB-SC-003] citadoPor: [KB-SC-001, KB-SC-003, KB-SC-012, KB-SC-013, KB-PR-024] --- # Why certified items cannot be edited or deleted _The most repeated question, and why the answer is the feature rather than a bug._ **Responde a:** how do I delete a certified document · I uploaded the wrong file to SmartCheck · can certified evidence be edited · right to erasure and evidence It is the first question nearly everyone asks, usually with some irritation: "I uploaded the wrong file, how do I delete it?" The short answer is that you do not. The long answer is more interesting. **En corto** - If it could be deleted, certifying would prove nothing. - A file uploaded by mistake is not a problem: certify the right one and both remain. - Having two versions does not hurt you; usually it helps. - The right to erasure of personal data is handled through your data protection procedure, not by deleting evidence by hand. ## The reasoning Imagine deletion were possible. Someone asks you to prove you held a certificate on 3 March, you show them, and the other side replies: "sure, but you could have uploaded that yesterday and deleted the old one". They would be right. The entire usefulness of certifying depends on nobody — including you — being able to alter it afterwards. So immutability is not an awkward restriction that would be nicer removed: it is precisely the product. An audit archive its owner can edit is not an audit archive. ## What to do when you get it wrong 1. **Do not try to undo it** — There is nothing to undo, and it is not a problem. Move on. 2. **Certify the correct document** — Upload it normally. It gets its own date, later than the wrong one. 3. **Name each one so you do not confuse them** — Metadata and labels can be adjusted: what does not change is the certified content. > [!NOTE] > Having two versions is almost never a problem. When someone asks you to account for something, the sequence is usually exactly what interests them: what was there before, what was corrected and when. ## And personal data It is a fair question: if someone exercises their right to erasure, what happens to evidence carrying their name? That case is not solved by deleting by hand from the interface — which is exactly what cannot be done — but through your organisation's data protection procedure, which covers retaining evidence held under a legal obligation. If a request like that reaches you, talk to whoever handles data protection before touching anything. ## Frequently asked questions **Can I rename it or move its folder?** Yes. What is immutable is the certified content and its date; the organisation around it can be adjusted. **Can I hide a piece of evidence without deleting it?** You can organise it and restrict who sees it within your organisation, but it does not disappear from the record. **What if I uploaded something confidential by mistake?** Talk to whoever handles data protection in your organisation. It is a foreseen case, but it is handled by procedure, not by deleting the record. **Does uploading the same file twice count as two certifications?** Each upload is a piece of evidence with its own date. If the file is identical, so is its fingerprint, and that is visible. ## Ejemplos **Someone certifies a report draft by mistake instead of the final version, and notices the next day.** - Certifies the final version, which gets today's date - Labels the first one "draft" to tell them apart - Leaves both where they are → The file shows there was a draft on the 3rd and a final version on the 4th, which is more credible than the final one appearing alone. **A document with a typo is sealed.** - Seals the corrected version and keeps both → The correction is explained rather than hidden. **Somebody asks to delete an evidence record for tidiness.** - Explains that immutability is what gives it value → The proof still counts because nobody can touch it. **Something is sealed by mistake.** - Seals the right version and documents the error → The history stays clear and verifiable. **Somebody is reluctant to seal for fear of not being able to amend.** - Reviews before sealing and seals successive versions → Sealing stops feeling irreversible. **Somebody asks why it cannot be edited.** - Compares with a document that can be edited → It becomes clear that editable and provable are opposites. --- --- id: KB-SC-003 url: https://app.codecontract.io/help/smartcheck/sharing-evidence-with-an-auditor idioma: en categoria: smartcheck subcategoria: compartir modulo: smartcheck audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-SC-001, KB-SC-002, KB-CO-004] citadoPor: [KB-SC-001, KB-SC-002, KB-CR-004, KB-TZ-001] enLaApp: https://app.codecontract.io/verify/search --- # Sharing evidence with an auditor _How to show certified material to an outsider so they can verify it themselves._ **Responde a:** how do I show evidence to an auditor · share a certified document with a third party · export the audit dossier · public verification of a document Certifying is not much use if, on the day you have to show it, the only option is emailing the file and asking people to take your word for it. What makes evidence useful is the other side being able to check it without depending on you. **En corto** - Each piece of evidence has a share link for people without an account. - There is a public verification page where anyone can check a document. - You can download a human-readable certificate to attach to a file. - For a whole audit, export the complete folder dossier. ## Sharing a single piece of evidence This is the common case: the auditor asks about one specific record. From the evidence you generate a link you can email. Whoever opens it sees the document and its certification details — what was certified, when, and with what fingerprint — without an account and without seeing the rest of your folder. ## Public verification This is the strongest of the three mechanisms, because it does not depend on a link you generated. Anyone holding the document can check on the public verification page whether it corresponds to a registered certification and from what date. That is what you give a lawyer or a court when they want to confirm it themselves. > [!NOTE] > If the document has been altered by even one character, verification does not match. That is what makes it worth something: it is not a decorative seal. ## The downloadable certificate A separate, human-readable document summarising what was certified, when, and with what fingerprint. Useful for attaching to a file or a report without having to send the original document, which is sometimes confidential. ## The audit dossier When what they ask for is not one record but "everything from the third quarter", you export the folder dossier: a package with the evidence and its certification details, ready to hand over in one go. It is the difference between spending an afternoon compiling and settling it in five minutes. ## Frequently asked questions **Does whoever opens the link see the rest of my folder?** No. The link is for that specific piece of evidence. It gives access to nothing else in your organisation. **Does the auditor need an account?** No. Neither for the shared link nor for public verification. That is precisely the point. **Can I tell whether someone opened the link?** Accesses are logged along with the rest of your organisation's traceability. **What if I want to show the date but not the content?** That is what the downloadable certificate is for: it attests what was certified and when, without handing over the original document. ## Ejemplos **An external auditor asks for a whole quarter's quality evidence — eighty records.** - Exports the dossier for the quarter's folder - Hands it over in a single delivery - Points them at the public verification page in case they want to check any independently → The auditor validates whatever they like without coming back to you, and you never had to hunt down eighty files. **An auditor wants to verify an evidence record themselves.** - Points them to the verification page → They verify without depending on you. **A screenshot is sent to them.** - Provides the document and its seal reference → They can verify rather than believe. **The auditor asks for the whole file and only one item is needed.** - Shares only the relevant evidence → What was asked for is delivered, and nothing more. **A record is needed of what was shown to them.** - Records what was shared and when → The handover is demonstrable afterwards. **The auditor does not know what the verification means.** - Explains exactly what the seal asserts → The proof is not credited with more than it says. --- --- id: KB-SC-004 url: https://app.codecontract.io/help/smartcheck/what-is-worth-certifying idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-001, KB-TZ-002] citadoPor: [KB-SC-005, KB-SC-006, KB-SC-007, KB-SC-009, KB-SC-012, KB-SC-015, KB-CF-008] --- # What is worth certifying _Certifying everything is noise. These are the cases where it genuinely matters._ **Responde a:** which documents should i certify · when to use smartcheck · is it worth sealing every document · what is certifying evidence for Certifying does one thing: it lets you prove later that something existed and said exactly this on a given date. If nobody will ever dispute that, certifying it adds nothing. ## Where it does | Document | What is protected | | --- | --- | | A delivery or handover note | That it was delivered that day and in that condition | | A technical report or survey | That it said this before there was a dispute | | A design, a formula, source code | That it was yours on that date | | Photos of a site or of damage | That they were taken when you say, not after | | An important communication | That it was sent and what it said | ## Where it does not - Drafts that will change next week. - Documents already signed: the signature carries its own date. - Copies of third-party official documents, which are verified at source. > [!IMPORTANT] > Certifying does not say the content is true. It says that content existed on that date. A certified report with invented figures still has invented figures, only with a trusted date. > [!NOTE] > The useful question is not "is this important?" but "could anyone dispute in two years what this said or when?". If yes, certify it. **Can I certify something old?** Yes, but the date certified is today's, not the original. **Does it take space or change the document?** The document does not change. What is stored is its fingerprint. **Does it still hold if I convert the file?** No: converting changes it. Certify the file you intend to keep. ## Ejemplos **An engineering practice delivers a report that may end up in litigation.** - Certifies the report on the day it is delivered → Two years later they can prove what it said before the dispute, without relying on their own filing. **Everything incoming is sealed and the listing stops being useful.** - Seals what could end up disputed → The listing says something again. **An agreement closed by email is not sealed.** - Seals the thread when the agreement closes → What was agreed can be proved later. **Drafts that will change are sealed.** - Seals on closing, not during → Each seal corresponds to something final. **There is doubt whether to seal a client deliverable.** - Seals it the day it is delivered → The delivery date stops being argued. **Something already signed is sealed.** - Checks whether the signature already provides the date → You do not pay twice for the same thing. --- --- id: KB-SC-005 url: https://app.codecontract.io/help/smartcheck/sending-proof-to-someone-outside idioma: en categoria: smartcheck subcategoria: compartir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-004, KB-TZ-002, KB-SC-019] citadoPor: [KB-SC-008, KB-SC-010, KB-SC-016] --- # Sending proof to someone outside _How to send something certified so the other side can check it themselves._ **Responde a:** send a certified document to a client · let my lawyer verify the document · share the proof with a third party · send evidence to a court Proof that can only be checked inside your own account is not much use: whoever needs to check it is always outside. So it is sent in a way they can verify without you. 1. **Send the document and its receipt** — Both together. The receipt is what allows verification without an account. 2. **Tell them where to check** — The public verification page. No sign-up required. 3. **Let them do it** — They upload the file and see whether it matches. If it depended on you showing them, it would not be worth the same. **En corto** - The recipient needs no account and no permission from you. - Verification does not run through your relationship: they do it with the file. - It works years later, as long as they keep the file. ## For a lawyer or a court Send the document, the receipt and a one-line note saying where it is verified. That is what avoids the argument about whether the file is the right one, which usually eats more time than the substance. > [!WARNING] > Send the original file, not a printout or a photo of the screen. Reprinting a PDF changes it, and verification will then say it does not match — correctly. **Can I send it by ordinary email?** Yes. The proof is in the file, not in how it travels. **What if they open it on a phone?** Same: verification works in any browser. **Do I find out they verified it?** Verifications are logged. ## Ejemplos **A client disputes the condition a machine was delivered in.** - Sends the certified photos from the delivery day and the receipt - Points them to the verification page → The client checks for themselves that the photos are from that day and the dispute ends. **The proof is emailed with nothing else.** - Sends the document and its verification reference → The other side verifies for themselves. **The recipient does not know how to check it.** - Explains the step in two lines → Verification happens without phone calls. **Only the fingerprint is sent and the document is missing.** - Decides what to send according to the case → The recipient gets what they need. **The file is re-saved on forwarding and stops matching.** - Sends the original without opening or re-saving it → Verification comes out correct. **Evidence of sending is needed.** - Records the send in the file → The delivery is proved too. --- --- id: KB-SC-006 url: https://app.codecontract.io/help/smartcheck/certifying-photos-and-field-evidence idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-004, KB-GL-005] citadoPor: [KB-SC-009, KB-CS-011, KB-SC-011, KB-SC-017] --- # Certifying photos of a site or a delivery _Making the photo prove when it was taken, which is what always gets disputed._ **Responde a:** certify site photos · prove the condition of a delivery · photos with a certified date · evidence of damage to goods A photo without a trusted date proves little: the date inside a file can be changed by anyone, and the other side knows it. Certifying them turns "this is how it was" into something that admits no argument. ## When it pays off | Moment | What is protected | | --- | --- | | Receiving goods | The condition they arrived in | | Handing over work | What was delivered and how | | Starting a job | The prior condition, before anything is touched | | Damage or an incident | That it happened when you say, not after | ## How to take them so they count **En corto** - One wide shot for context, then the details. - Include something that anchors the place: a serial number, a registration, a sign. - Certify them the same day, not when the problem appears. > [!IMPORTANT] > Certifying months later fixes nothing: the certified date is today's. If the photos matter, the moment to certify them is the day they are taken. > [!WARNING] > Do not retouch or crop photos before certifying. Any edit changes the file, and the other side will ask why it was edited. > [!NOTE] > Prior condition is the most forgotten and the most argument-saving: four photos before starting costs two minutes and closes the "that was already broken" claim. **How many photos can I certify at once?** A whole set, certified as a set. **Does a phone photo count?** Yes. What is certified is the file, not the camera. **Can it be shared with the client?** Yes, and they can verify without an account. ## Ejemplos **An installer receives a claim for damage that predated their work.** - Retrieves the certified photos from the day they started → The claim closes in an afternoon; without them it would have been their word against the client's. **A site photo carries no provable date.** - Seals the photo the same day → The date stops being argued. **Photos live on the foreman's phone.** - Uploads and seals them from that phone → The record outlives the handset. **There is a dispute whether damage predated a delivery.** - Seals the receipt photos → The initial condition is provable. **A hundred photos are taken and sealing one by one is impractical.** - Seals the set at once → The cost does not grow with the number of photos. **The photo is sealed weeks after being taken.** - Seals at the moment of capture → The seal says what you want it to say. --- --- id: KB-SC-007 url: https://app.codecontract.io/help/smartcheck/what-certifying-evidence-means idioma: en categoria: smartcheck subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-004, KB-GL-005] citadoPor: [KB-SC-018, KB-SC-020] --- # What certifying something means _Being able to prove later that something existed and said this._ **Responde a:** what is smartcheck · what certifying a document is for · what sealing evidence means · how do i prove i had this earlier Certifying something is leaving a record, checkable by anyone, that a specific file existed exactly as it stands on a given date. No more and no less — and it turns out that is exactly what gets disputed when there is a problem. **En corto** - It certifies when, not whether what it says is true. - Anyone can check it, with no account and without asking you. - The document does not change: its fingerprint is stored, not a different copy. ## What problem it solves When two parties disagree about what was delivered, when notice was given, or what condition something was in, it is almost always one person's word against the other's. Certifying turns your version into something checkable: it does not depend on being believed. ## What usually gets certified - A report or survey, on the day it is issued. - Photos of a delivery or of a site's prior condition. - A design, a formula or a piece of work, to date its authorship. - An important communication and what it said. > [!IMPORTANT] > Certifying does not say the content is true: it says that content existed on that date. A certified report with invented figures still has invented figures, only with a trusted date. > [!WARNING] > The date certified is today's. Certifying something from three years ago does not prove it is three years old: if something matters, certify it the day it is made. **How long does it take?** It is immediate. **Does the other party have to agree?** No. Verification does not depend on your relationship. **Does it work years later?** Yes, as long as the file is kept. ## Ejemplos **A surveyor delivers a report that may end up disputed.** - Certifies it the day it is signed → Two years later they can prove what it said before the dispute existed, without relying on their own filing. **People think certifying stops somebody copying something.** - Understands it certifies existence, not exclusivity → The proof is not credited with what it does not do. **What must be proved is that something was said, not that a file exists.** - Seals the notice or the communication → What is proved is what was needed. **A document is sealed and then modified.** - Seals each final version → Each seal points at an exact content. **There is a question whether a third party will accept it.** - Checks what can be verified and how → Expectations are set before they are needed. **The evidence is kept and the file is lost.** - Keeps both together → The proof stays complete. --- --- id: KB-SC-008 url: https://app.codecontract.io/help/smartcheck/keeping-proof-for-many-years idioma: en categoria: smartcheck subcategoria: compartir audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-005, KB-TZ-002] citadoPor: [KB-SC-019, KB-CO-020] --- # Keeping proof for many years _What it takes for it to still hold in ten years._ **Responde a:** how long does a seal remain valid · long-term preservation of signed documents · re-sealing old documents · will it still hold in ten years A seal does not expire with time, but the cryptography behind it ages: what is impossible to forge today may not be in twenty years. For documents that have to last, that needs anticipating. ## What is needed and when | Document's lifespan | What it needs | | --- | --- | | Under 5 years | Nothing special. Keep the file | | 5 to 15 years | Keep the original file, unconverted | | Over 15 years | Plus re-sealing before the algorithm becomes obsolete | ## What usually fails is not the cryptography It is losing the file. Documents that stop being provable after ten years rarely fail on the algorithm: they fail because nobody knows where the file is, or because someone converted it to another format "to archive it better" and thereby changed its fingerprint. > [!IMPORTANT] > Converting a sealed file to another format invalidates it as evidence. Keep the original exactly as it was sealed, and if you need a copy in another format, make it an additional copy, not a replacement. ## What to keep, exactly - The original file, byte for byte. - The sealing receipt. - And knowing where both are in ten years, which is the hard part. > [!NOTE] > If the document lives on the platform, your retention policy covers this. The problem appears with copies people take to their own drives and later reorganise. **Am I warned when re-sealing is due?** Ask about it for your long-lived documents: it is not something to discover late. **Does re-sealing change the document?** No. It adds a new layer over the same fingerprint. **What if I lose the receipt?** If the document is on the platform, it is recovered. If you only had a loose copy, that is the problem. ## Ejemplos **An engineering practice keeps projects that may be disputed twenty years later.** - Keeps the originals unconverted - Asks about re-sealing for the longest-lived ones → The projects remain provable when a claim appears fifteen years on. **The proof is stored in a format nothing will open in ten years.** - Keeps the original in a standard format → The file stays readable. **The evidence lives on a machine that gets retired.** - Stores it off personal machines → Migration does not take the proof with it. **The document is kept and the seal reference is lost.** - Keeps document and reference together → Verification stays possible. **Systems change and the history is left behind.** - Includes the proof in the migration plan → The evidence survives the change. **Nobody ever checks whether the proof still verifies.** - Verifies a sample periodically → A problem is found before the proof is needed. --- --- id: KB-SC-009 url: https://app.codecontract.io/help/smartcheck/certifying-an-important-communication idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-004, KB-SC-006] citadoPor: [KB-SC-011, KB-SC-014] --- # Certifying that you said what you said _When what needs proving is not a document but a notice._ **Responde a:** prove i sent an important notice · certify an email · proof that i communicated something · digital alternative to recorded delivery Some communications are not documents and still need proving: notice of a cost overrun, notice of a defect, a warning that a deadline will slip. They get disputed just like a contract, and usually with less evidence behind them. ## What exactly gets certified **En corto** - The full text of what you communicated. - The date, set by a third party rather than by you. - Who it was addressed to. What it does not certify is that the other party agreed. That needs their signature, which is a different and stronger thing. ## Notify or get it signed | If what you are communicating... | Do this | | --- | --- | | Is informative and changes nothing | Notify; the send record is enough | | May have financial consequences | Certify the communication | | Modifies what was agreed | Send it for signature, not as a notice | _The gap between "I told you" and "you accepted" is the whole difference._ > [!IMPORTANT] > Certifying a communication does not replace notification methods required by a contract or a rule. If your contract says communications go through a specific channel, that channel remains mandatory; this is additional evidence, not a shortcut. > [!WARNING] > Certify the text you actually sent, not a summary of what you remember sending. A reconstructed text proves nothing and, if the original turns up and differs, it weakens your position. > [!NOTE] > The most useful thing is usually the dullest: certifying, at the time, the email warning about the delay — not the fifty-page report at the end. **Is it the same as recorded delivery?** They are different things and worth asking your adviser about for your case. This proves content and date; recorded delivery adds a postal operator. **Can I certify it days later?** You can, but the certified date is today's. If it matters, do it the same day. **Can the other party check it?** Yes, with no account, on the public verification page. ## Ejemplos **A builder tells a client that a design change will increase costs.** - Certifies the email the same day it is sent → When the overrun is disputed four months later, the date and the text do not rest on their word. **A warning was given by phone and there is no record.** - Sends the warning in writing and seals it → The warning stops depending on two memories. **A warning was emailed and the other side says it never arrived.** - Seals the send with its date → It is on record when it was communicated. **Warning comes late and you want to prove it was given.** - Seals the warning the day it goes out → The warning's date is beyond dispute. **The warning goes to the wrong recipient.** - Checks the recipient before sealing → The seal proves something useful. **Every email is sealed out of habit.** - Seals the warnings that could be disputed → The history stays manageable. --- --- id: KB-SC-010 url: https://app.codecontract.io/help/smartcheck/what-to-do-if-verification-fails idioma: en categoria: smartcheck subcategoria: compartir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-005, KB-TZ-002] citadoPor: [KB-SC-013] --- # If verification says it does not match _It is almost never fraud. The four real causes, by frequency._ **Responde a:** verification says it does not match · the document will not verify · error verifying a document · the hash does not match what does it mean It says "does not match" and the first instinct is to think someone tampered with the document. It is almost never that. These are the four real causes, and fraud is the least frequent. | Cause | How to spot it | What to do | | --- | --- | --- | | The file was reprinted or re-saved | It looks the same, weighs differently | Ask the sender for the original | | It was converted to another format | The extension changed | Ask for the original in its format | | It came from a much-forwarded email | Usually with a changed filename | Request it from source | | It is a different document | Here it is worth asking | Check with whoever issued it | > [!IMPORTANT] > The first three are things anyone does without ill intent: opening a PDF and saving it from another program modifies it even if the content looks identical. Before raising a suspicion, ask for the original file — it resolves ninety per cent of cases. ## How to ask for the original without accusing "The file is not verifying for me — it has probably been re-saved along the way. Could you send me the original exactly as it reached you?" achieves the same as a suspicion and breaks nothing if, as is likely, there was nothing to suspect. ## When to be concerned **En corto** - The sender sends the same file twice and it still does not verify. - The document says something different from what you remember agreeing. - And it arrives urgently, through an unusual channel, from someone you were not expecting. > [!WARNING] > If all three coincide, do not treat it as a technical problem. A document that fails verification, says something different and arrives urgently through an odd channel is the pattern of an impersonation: phone the number you already had before acting on it. > [!NOTE] > "Not found" is different from "does not match". Not found means that document was never sealed here: it may be from another issuer, or simply not certified. **Can I find out what changed?** No. The fingerprint says it changed, not what. **What if the original does not verify either?** Then yes, check with whoever issued it. **Does a scanned printout verify?** No. It is a new file, even if the content is identical. ## Ejemplos **A client reports that a certificate you sent does not verify.** - Asks for the file exactly as they received it - Finds they had re-saved it from their email client → Resolved in five minutes without anyone raising a suspicion that was never warranted. **The file was opened and re-saved.** - Checks against the untouched original copy → Verification comes out correct. **A file converted to another format is checked.** - Verifies the file exactly as sealed → The conversion stops looking like tampering. **It is compared against a different version of the document.** - Confirms which version was sealed → Like is compared with like. **The file arrived through a channel that recompresses it.** - Requests it again uncompressed → The fingerprint matches again. **It genuinely does not match and there is no explanation.** - Documents the check and escalates → The case is handled with the trail in view. --- --- id: KB-SC-011 url: https://app.codecontract.io/help/smartcheck/certifying-what-a-web-page-said idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-009, KB-SC-006, KB-SC-014, KB-SC-017] citadoPor: [KB-LE-012] --- # Certifying what a web page said _A price, a condition or a post that may be gone tomorrow._ **Responde a:** certify the contents of a web page · prove what a website said on a date · screenshot with evidential value · capture a post before it is deleted What is published online changes without warning. A price, terms of service, a product sheet, a social post: the screenshot you took proves little on its own, because anyone can fabricate one. ## What turns a screenshot into evidence | Element | Why it matters | | --- | --- | | A provable date | Without it there is just an image with no moment | | That it cannot be altered afterwards | It is what removes the suspicion of retouching | | The exact address | "It was on their site" points at nothing | | Who captured it | Evidence without an author weighs half | > [!IMPORTANT] > The first is what actually settles the dispute. The argument is never whether the page says that today: it is whether it said it on the day you decided something based on it. ## When it is worth doing **En corto** - Before buying on published terms. - When a competitor publishes something that affects you. - If you are going to claim over an offer that later changed. - And for any post that could vanish within hours. ## How to do it 1. **Capture the full page, not a crop** — A crop leaves out context and that is the first thing disputed. 2. **Note the exact address and time** — The full address, not the site's homepage. 3. **Certify the file on upload** — That fixes that it existed at that moment and has not changed since. 4. **And keep it in the matter's file** — Loose evidence nobody can find two years later is worth nothing. > [!WARNING] > Certifying a capture proves that file existed on that date and has not changed. It does not prove the page was genuine or unmanipulated at capture time: for that, when a lot is at stake, the notarial route exists and remains the most solid. ## The same applies to other ephemeral things A message that can be deleted, an advert that is pulled, a document posted temporarily: the mechanics are identical and so is the value. What matters is doing it when you see it, not when the dispute starts — by then it has usually gone. > [!NOTE] > Certifying is an action and consumes like any other. Even so, it is infinitely cheaper than reconstructing something that no longer exists. **Does it stand up in court?** It provides date and non-alteration, which is a lot. Final weight is for the court to decide. **What if the site requires a login?** You can still capture it; it helps to show you were legitimately inside. **Do I need to certify daily?** No: only when the content matters for a decision or a claim. ## Ejemplos **A company buys on published terms that later change.** - Had certified the page on the day of the order - Produces the dated file when claiming → The claim is settled on what the site said that day, not on what it says now. **A condition on a website changes and can no longer be proved.** - Seals the capture the day it is consulted → What it said becomes provable. **A screenshot is kept with no provable date.** - Seals the capture as well as keeping it → The date does not depend on the computer. **Only part of the page is captured.** - Captures the whole page with its address → Context accompanies the proof. **It is sealed months after being seen.** - Seals at the moment of consultation → The seal proves when it was seen. **A price published on a date must be proved.** - Seals the consultation that day → That day's price is on record. --- --- id: KB-SC-012 url: https://app.codecontract.io/help/smartcheck/certifying-many-things-at-once idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-004, KB-SC-002] citadoPor: [KB-SC-017] --- # Certifying many things at once _A month-end, a photo campaign or a whole archive. What deserves a seal and what does not._ **Responde a:** certify many documents at once · sealing an entire archive · batch certification · is it worth certifying everything When people discover what certifying is for, the temptation is to seal everything. And although technically possible, it is rarely the best idea: certifying makes sense where a dispute over date or content could arise, and across most of an archive that dispute will never happen. ## What is worth it | Worth sealing | Usually unnecessary | | --- | --- | | What proves you gave notice in time | Internal working documentation | | Field photos and evidence | Drafts and working versions | | What supports a claim | What already comes signed and dated by a third party | | What may disappear at source | Copies of something already sealed | > [!IMPORTANT] > The last row on the right saves the most. Certifying a copy of something already certified adds nothing: the proof is in the original and travels with it. ## When batching makes sense 1. **At the close of a period** — End of site, end of season, file closure. All together, same date. 2. **After a day in the field** — The day's photos and reports, on return, in a single batch. 3. **Before something changes** — If you know a website, catalogue or price is about to change. 4. **And on receiving an alert or a claim** — Whatever exists at that moment, sealed now: from then on everything gets disputed. > [!WARNING] > What makes no sense is sealing the whole historical archive "just in case". Seal what could end in dispute; the rest only consumes and adds noise around what matters. ## How to know it worked **En corto** - Anyone outside can verify it without asking you for anything. - The date does not depend on your system or your word. - And the file can be verified years later, even if you are no longer customers. That third point usually settles the question of whether it pays: the evidence does not expire with your relationship with the platform. > [!NOTE] > Each certification is an action and consumes. Hence the list above: it is not a technical restriction, it is that sealing what nobody will dispute is money buying nothing. **Can I certify something old?** Yes, but it fixes today's date, not the original one. For old material it proves less than it seems. **What if the file changes afterwards?** It stops verifying, which is exactly the point. **Is it needed for what is already signed here?** No: the signature carries its own evidence. ## Ejemplos **A company wants to certify its twenty thousand historical documents.** - Seals only what could end in dispute and what expires - Leaves the rest unsealed → Gets the same practical protection for a fraction of the consumption. **A whole history is sealed with no criteria.** - Seals what could end up disputed → The listing stays readable. **A month-end close is sealed document by document.** - Seals the set at once → Cost and time do not grow with volume. **A photo campaign is sealed without identifying the photos.** - Adds project reference and date before sealing → Each photo is locatable afterwards. **Everything is sealed and nobody knows what each item is.** - Organises before sealing → The seal rests on something ordered. **Sealing is postponed until there is time.** - Seals at the close of each period → Work does not pile up into something that never gets done. --- --- id: KB-SC-013 url: https://app.codecontract.io/help/smartcheck/what-if-i-lose-the-original-file idioma: en categoria: smartcheck subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-002, KB-SC-010, KB-SC-020] citadoPor: [KB-SC-015] --- # What if I lose the original file? _What can still be proven without the file, and why it is best not to get there._ **Responde a:** i lost the certified document · can it be verified without the file · what if i delete a sealed document · recovering certified evidence Certifying a document does not store a copy somewhere else in the world: it fixes a fingerprint that lets you check that **that** file is the same one that existed on that date. The practical consequence is direct: if the file disappears, the check has nothing to work on. ## What survives and what does not | Still exists | No longer possible | | --- | --- | | The record that something was certified, and when | Checking a file matches, with no file | | The fingerprint of that content | Reconstructing the content from the fingerprint | | The record of who did it | Proving exactly what the document said | > [!IMPORTANT] > The second row on the right surprises people: the fingerprint is not a compressed copy, and you cannot work back from it. It proves a file is the same one; it does not let you recover it. ## How to avoid the problem 1. **Keep the document in its file, not only on a machine** — That is what stops it depending on a disk or a person. 2. **Download copies of what is genuinely critical** — Whatever supports a large claim, keep outside as well. 3. **And do not delete old material to make room** — It takes little space and its value appears years later, exactly when it is gone. > [!WARNING] > Beware automatic retention deletion. If you have a policy that deletes after X years, check it does not sweep up certified documents supporting something with a longer claim window. ## If it has already happened **En corto** - Check whether someone outside has a copy: the other party, the adviser, the client. - Any copy works, provided it is exactly the same file. - And if a different version turns up, it will not verify — which is also information. That last point has a positive reading: if a recovered copy verifies, you know with certainty it is the original document and not a version altered along the way. > [!NOTE] > The commonest loss is not a technical failure: it is a document that only existed in the email or desktop of someone who has left. The answer is not more backups; it is that it should never have lived there. **Does the platform store my documents?** Yes, what is uploaded is there and can be downloaded. The risk is what was never uploaded. **What if I stop being a customer?** You can export everything; and certified material can still be verified afterwards. **Is a paper printout enough?** To read it yes, to verify no: the check is on the exact file. ## Ejemplos **A company certifies a report and keeps it only on the author's laptop.** - Uploads the report to the matter's file - Also downloads a copy of what is critical → The day that laptop fails, the document is still there and still verifies. **The file is lost and only the reference remains.** - Checks what can be asserted without it → You know what you actually have. **The file sits on a machine that failed.** - Keeps a copy in more than one place → The loss stops being total. **Only the seal reference is kept.** - Keeps document and reference together → The proof is complete. **The loss is discovered when the proof is needed.** - Verifies a sample periodically → The problem is discovered sooner. **The file was held by somebody who left.** - Stores evidence off personal machines → Somebody leaving does not take the proof. --- --- id: KB-SC-014 url: https://app.codecontract.io/help/smartcheck/certifying-an-agreement-made-by-email idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-009, KB-TZ-012] citadoPor: [KB-SC-011] --- # Certifying an agreement made by email _What was agreed in an email thread exists. Whether it can be proven a year later is another matter._ **Responde a:** evidential value of an email · certifying an agreement by email · does email count as a contract · proving what was agreed in writing A considerable share of real agreements is closed in an email thread: a price, a deadline, a special condition. That counts, but the evidence lives in two private mailboxes and degrades over time — messages get deleted, systems change, people leave. ## What to do when the agreement matters 1. **Summarise it in a closing message** — "To confirm: we agreed X, with deadline Y and condition Z." One paragraph, unambiguous. 2. **Ask for explicit confirmation** — A clear "agreed"; silence is not acceptance in most cases. 3. **Keep it in that relationship's file** — With the full thread, not just your summary. 4. **And certify it if the amount or risk justifies it** — It fixes that the content existed on that date and has not changed. > [!IMPORTANT] > The first step is worth more than the other three together. Most later disputes are not about whether there was an agreement, but about exactly what was agreed — and a confirmed closing summary removes that argument entirely. ## What a certified email proves and does not | It proves | It does not prove | | --- | --- | | That the content existed on that date | That the other party read it | | That it has not changed since | That the writer had authority to bind | | That it was in your possession | That the agreement is valid if the law requires another form | > [!WARNING] > The second row on the right matters with companies: whoever negotiates by email cannot always commit their company. For significant agreements, have someone who can sign do so, and that is no longer an email: it is a signature. ## When it is worth moving to signature **En corto** - When the amount justifies a dispute. - When the agreement changes terms of an existing contract. - When deadlines start running from it. - And when the other party changes contact person frequently. In those four cases, a signature request costs the same as the time spent writing the closing email and leaves far stronger evidence: identity, moment and exact content accepted. > [!NOTE] > None of this invalidates email. A well-kept thread, with a confirmed and certified summary, is reasonable evidence for the vast majority of commercial relationships; moving to signature is for when something important is at stake. **Does a text message count?** As an indication yes; with the same limits as email, and easier to lose. **Must the whole thread be certified?** The closing message and confirmation suffice, keeping the whole thread. **What if the other side denies it?** That is where a provable date and unaltered content do their work. ## Ejemplos **Two companies agree a volume discount across a twenty-email thread.** - Write a closing message and ask for confirmation - Keep it certified in the client's file → A year later, with a different contact, the agreement is not disputed. **An agreement closes in an email thread and nobody seals it.** - Seals the thread when it closes → What was agreed is provable a year later. **The thread keeps growing after the agreement.** - Seals the exact point of agreement → The seal points at the agreement, not the whole conversation. **A single email is sealed without context.** - Seals the complete thread → The proof is understood without explanation. **Each party keeps their own version of the thread.** - They share the seal reference → Both parties refer to the same thing. **A contract is signed and the earlier thread is discarded.** - Keeps the thread that explains what was agreed → The context outlives the contract. --- --- id: KB-SC-015 url: https://app.codecontract.io/help/smartcheck/what-certifying-does-not-solve idioma: en categoria: smartcheck subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-013, KB-SC-004] citadoPor: [KB-SC-020] --- # What certifying does not solve _Four things people expect from a seal that it does not provide, and what to use instead._ **Responde a:** what does certifying a document actually prove · does a seal prove it is true · limits of evidence certification · does certifying prove authorship Certifying does one thing and does it very well: it fixes that a specific file existed on a date and has not changed since. Almost all misunderstandings come from expecting four further things that are not included — worth knowing before resting a claim on it. ## The four it does not give | What many people expect | The reality | What actually helps | | --- | --- | --- | | That it proves the content is true | It proves the file said that, not that it was true | The source document and whoever answers for it | | That it proves who created it | It proves possession on a date, not authorship | Contracts, intermediate versions and the trail of work | | That it proves the other side read it | That is outside the seal | The record of sending, delivery and opening | | That it keeps a copy safe | It keeps a fingerprint, not the file | Keeping the document in its file, plus a copy of what is critical | > [!IMPORTANT] > The first row causes the most confusion in commercial conversations. A sealed delivery note proves that note, with that text, existed on the 4th — it does not prove the goods were delivered. The seal protects the document's **integrity and date**; what the document asserts is still worth whatever whoever signed it is worth. ## Where it does change the outcome **En corto** - When the argument is about when notice was given or when something existed. - When someone claims a document was modified afterwards. - When something may disappear at source: a web page, a post, a message. - And when the evidence has to outlive your change of system or provider. In those four cases it adds something no other measure provides as cheaply, which is why it is worth having in the right places rather than everywhere. > [!WARNING] > The nuance nobody deduces: verification is done on the **exact** file. If someone opens the PDF and saves it again, or compresses it, or prints and scans it, it is already another file and will stop verifying even though it reads identically. When you send evidence to a third party, send the file as it is, without touching it "to make it smaller". ## How it works alongside the rest 1. **Sign when what matters is that someone accepts something** — A signature adds identity and consent; a seal adds integrity and date. 2. **Record the send when what matters is that it arrived** — Delivery and opening are separate evidence. 3. **And certify when what matters is that it has not changed** — The three complement each other and none replaces the other two. > [!NOTE] > That a third party can verify it without asking you for anything is half the value: if verifying requires trusting you, you have added little to simply keeping the file. **Does it stand up in court?** It provides date and integrity, which is a lot. Final weight is for the court, alongside the rest of the evidence. **What if the file is lost?** The check has nothing to work on: the fingerprint does not reconstruct content. **Should I certify everything just in case?** It does not pay: sealing what nobody will dispute consumes and adds noise. ## Ejemplos **A company seals every delivery note believing it proves the deliveries.** - Understands the seal proves the document, not the event - Adds the recipient's signature at delivery → It can now evidence the delivery, not merely that the note existed. **A seal is expected to stop somebody copying an idea.** - Understands it proves existence, not exclusivity → Expectations are set before they are needed. **A seal is expected to bind the other party.** - Signs whatever must bind → Each tool does its own job. **It is expected to validate the document's content.** - Understands it proves what it said, not whether it was true → It is not credited with a verification it does not perform. **It is expected to replace an official register.** - Checks with the adviser what each case requires → The seal complements rather than replaces. **It is expected to organise the archive.** - Organises before sealing → The seal rests on something ordered. --- --- id: KB-SC-016 url: https://app.codecontract.io/help/smartcheck/the-public-verification-page idioma: en categoria: smartcheck subcategoria: compartir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-005, KB-TZ-008] citadoPor: [KB-SC-019] --- # The public verification page _Anyone can check evidence of yours without asking you, and without you showing them the document._ **Responde a:** how a third party verifies a sealed document · public authenticity check page · what the verification qr shows · checking a seal without an account Evidence only you can check is of little use. Hence a public page where anyone — a client, an auditor, an expert witness, a court — can check for themselves whether something is sealed, with no account, without asking you, and with you taking no part. ## How it works, in one sentence > [!IMPORTANT] > The check runs **on the file's fingerprint, not on the file**. Whoever verifies does not upload your document anywhere: they compute its fingerprint and look it up. The practical consequence is twofold — you share the content with nobody in order to be believed, and the page cannot show what the document says, because it does not have it. ## What the page finds | If the hash matches… | What it shows | | --- | --- | | A certified piece of evidence | That it exists and since when it has been sealed | | A document version | That this specific version is registered | | A traceability event | The sealed event and its moment | | A sealing batch | Everything that batch sealed, not just one item | | Nothing | That there is no record: which is also an answer | ## The two ways in 1. **With the QR** — Scan it and it goes straight to that item's check. It is what goes on a delivery note, a label or a report. 2. **With the fingerprint** — Whoever holds the file computes its fingerprint and checks it. You need not send them any link. > [!WARNING] > The case that wrong-foots first-time users: if the file has been re-saved, compressed, or printed and scanned, **the check will say there is no record** even though it reads identically. That is not a failure: it is exactly the point. So when you send evidence to a third party, send the file as it is, without shrinking it. ## What the page does NOT show **En corto** - The document's content: the check is on the fingerprint. - Your internal data or the file it belongs to. - Nor who else has checked it. That is precisely why it can be left public: it shows that something is sealed and since when, not what it says or whose it is. > [!NOTE] > Generating the public QR is an action and consumes, like certifying. Putting it where someone will actually scan it — a label, a certificate, a report that goes outside — pays; putting it on everything by default does not. **Does it still work if we stop being customers?** The check is on the fingerprint and the seal; it does not depend on you staying. **Can someone verify something we never gave them?** Only if they have the file or the link. Without the fingerprint there is nothing to look up. **What if the page says there is no record?** Either the file changed or it was never sealed. Both are useful information. ## Ejemplos **A client doubts whether a certificate you sent is the original.** - You tell them to check the file's fingerprint on the public page → They verify it themselves in a minute, with nothing more to send and no access to grant. **A client wants to verify without asking you for anything.** - Gives them the verification reference → They verify themselves, with no intermediary. **There is a fear that verifying requires showing the document.** - Verifies with the fingerprint alone → Verification does not reveal the content. **The verifier does not know what the result means.** - Explains exactly what it asserts → The proof is not credited with more than it says. **The check errors because of a re-saved file.** - Verifies the original without opening it → The result is correct. **You want a record that somebody verified.** - Records who was given the reference → The handover is documented too. --- --- id: KB-SC-017 url: https://app.codecontract.io/help/smartcheck/certifying-a-stocktake-or-inventory idioma: en categoria: smartcheck subcategoria: certificar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-006, KB-SC-012] citadoPor: [KB-SC-011] --- # Certifying a stocktake or inventory _Recording what existed and in what condition on a specific date, which is what nobody can reconstruct later._ **Responde a:** certifying an inventory · recording a stock count · proving the condition of premises on a date · asset inventory with evidence There are moments when what matters is not a document someone sends you, but the state of things: what stock existed at year end, what condition premises were in when you moved in, what equipment was in a warehouse before a move. That does not arrive by email — it has to be created, which is why it rarely exists when needed. ## When it is worth doing | Moment | What it protects | Who asks later | | --- | --- | --- | | Year end | The count supporting the accounts | Auditor or adviser | | Moving into or out of leased premises | The condition received or handed back | The landlord, when the deposit is claimed | | Before a move or building works | What was there and how it was | The insurer, if something turns up damaged | | Change of warehouse manager | What is handed to whoever takes over | Both parties, if something later goes missing | > [!IMPORTANT] > The fourth row is done least and prevents the most internal conflict. When someone takes over a warehouse with no record of what was there the day they took it, any later discrepancy is theirs by default — which is unfair and hard to argue without a starting point. ## How to do it so it counts 1. **Photos with judgement, not a hundred photos** — A wide shot of the whole and detail of what matters: damage, valuables, meters. 2. **A written list alongside the photos** — Photos prove condition; the list says what was counted and how much. 3. **Signed by whoever was present** — If two parties, better both: it turns a record into an agreement. 4. **And certified the same day** — It fixes the date. An inventory certified three weeks later does not evidence that day's condition. > [!WARNING] > The nuance that makes it genuinely useful: **certify the set, not each photo separately**. One document with the list and the images inside, sealed once, is a single piece that is understood and checked as a whole. Fifty individually sealed photos are fifty loose exhibits someone will have to relate to each other, and that work will be done by whoever disputes it, not by you. ## What to include that hardly anyone includes **En corto** - The date and time, visible in the document itself. - Who was present, by name. - What could NOT be checked, stated explicitly. - And meter readings, if the place has them. The third seems to subtract and adds: an inventory that admits what was not reviewed is far more credible than one pretending everything was inspected. > [!NOTE] > Certifying the document is an action and consumes like any other. A yearly inventory, a change of premises or a handover of responsibility are exactly the cases where that cost is beyond argument. **What if a third party does the inventory?** Have them sign it and you keep it: their report with your record of receipt. **Does it work for a partial count?** Yes, stating its scope: what was not counted is information too. **Must it be repeated every year?** If it supports accounts or a contract, yes: last year's proves last year. ## Ejemplos **A company hands back leased premises and the landlord claims for pre-existing damage.** - It had certified the condition and meter readings on move-in day, with photos and a signed list → The dispute closes in one conversation instead of a deposit claim. **A stocktake happens and no record of the state remains.** - Seals the inventory the day it closes → What was there that day is provable. **There is a dispute about what existed on a given date.** - Checks the sealed inventory for that date → The dispute closes on the record. **The count is kept in a spreadsheet that is later edited.** - Seals the closed version → Later editing does not erase what was counted. **The count is sealed without identifying the warehouse.** - Includes location and date before sealing → The seal proves something specific. **The count must be handed to a third party.** - Shares the sealed inventory and its reference → The third party verifies without depending on you. --- --- id: KB-SC-018 url: https://app.codecontract.io/help/smartcheck/seal-or-sign-which-do-i-need idioma: en categoria: smartcheck subcategoria: empezar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-007, KB-CO-002, KB-TL-019] citadoPor: [KB-SC-020] --- # Seal or sign? Which do I need _They get mixed up constantly and answer different questions: one says «this existed», the other «I accept this»._ **Responde a:** difference between sealing and signing a document · do I need a signature or is certifying enough · certifying a document without signature · how do I prove it existed earlier It is the doubt that wastes most time at the start, and the answer is simpler than it looks: they do not compete. Sealing answers «this existed like this on this date». Signing answers «this person accepted it». Almost every tangle comes from using one to answer the other's question. ## Which answers which question | What you need to prove | What to use | Why | | --- | --- | --- | | That a document has not changed since | Seal | It fixes the exact content and the moment | | That the other party agreed | Sign | It is a person's act, not a state of the file | | That you sent a notice in time | Seal | What matters is the when, not acceptance | | That terms were accepted | Sign | And keeping what was shown at signing | | That a site photo is from that day | Seal | There is nobody who has to accept anything | > [!IMPORTANT] > The part almost nobody sees coming: **a signature does not by itself freeze what surrounded it**. It signs the document, not the annex it referred to, nor the email with the terms, nor that day's version of the price list. If the dispute is about those, what saves you is having sealed that material separately. Signing and sealing together is not redundant — they cover different layers of the same agreement. ## How to decide in ten seconds **En corto** - Is there someone who has to say yes? Then sign. - Do you only need nobody to be able to dispute the content or date later? Then seal. - Both? Sign the document and seal what comes with it. - And when in doubt, look at who will ask: a client asks for a signature, an auditor asks for a date. > [!WARNING] > There is an asymmetry worth being clear about: **what is signed already carries a seal inside** — the moment is fixed as part of the signature — but **what is sealed is signed by nobody**. Certifying a quote does not mean the client accepted it; only that it said that on that day. Confusing the two leads to treating as closed something nobody agreed to, and that surfaces late. ## The cases most often got wrong 1. **An acceptance note** — Sign: someone accepts they received what it says. 2. **A work report with photos** — Seal for the photos; sign only if the client has to approve it. 3. **A communication with consequences** — Seal: the content and date matter, not the other side's approval. 4. **New terms** — Sign, and seal the terms document that was shown to them. > [!NOTE] > Which signature level suits each document, and how each kind of evidence is weighed, depends on the framework that applies to you — **eIDAS** in Europe, among others — and on the type of contract. **Your adviser decides that**; here we explain what each tool is for. **Does sealing cost more than signing?** They are different actions and each consumes its own; the expensive part is choosing wrong. **Can I seal something already signed?** Yes, and it makes sense for the material that accompanied the document. **Is sealing an email worth it?** Yes, and it is one of the uses most appreciated later. ## Ejemplos **A company signs new terms with a client and attaches a price annex.** - Signs the document and separately seals the annex shown that day → When the client disputes the price months later, there is a record of which annex it was. **Something that needed signing is sealed.** - Signs whatever somebody must accept → The document binds whoever signs it. **Something that only needed dating is signed.** - Seals whatever only has to exist on a date → Nobody is asked to sign unnecessarily. **You want to prove existence and acceptance at once.** - Signs and keeps the signature's date → Both questions are covered. **Nobody knows which to choose for a given case.** - Asks what has to be demonstrable → The choice comes from the question rather than from habit. **An already signed contract is sealed.** - Checks whether the signature already provides the date → Neither the work nor the cost is duplicated. --- --- id: KB-SC-019 url: https://app.codecontract.io/help/smartcheck/handing-an-evidence-bundle-to-an-expert idioma: en categoria: smartcheck subcategoria: compartir audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-008, KB-SC-016] citadoPor: [KB-SC-005] --- # Handing an evidence bundle to an expert _When what you kept separately has to travel together to a lawyer, an expert or a court, and arrive checkable._ **Responde a:** preparing evidence for an expert · handing documents to a lawyer with validity · sending evidence to a court · keeping the file verifiable The day comes when what you certified over two years has to leave your organisation as a single bundle. And there the question is no longer whether you have the evidence: it is whether it will arrive in a state where the recipient can check it themselves. ## What the bundle must carry | Piece | What it is for | What happens if missing | | --- | --- | --- | | The original files, untouched | They are what gets checked | Without them there is nothing to verify | | Each one's seal or record | Fixes content and moment | You are left with a file whose date cannot be proven | | How to check it, explained | So the recipient does it alone | You have to do it for them, and that counts for less | | An index of what each item is | So it is understood without calling you | The expert works blind and asks about everything | | The context: what happened and when | It orders the reading | Each document is read in isolation | > [!IMPORTANT] > There is a technical error that ruins whole bundles and is invisible while doing it: **if you convert the file, it stops matching its seal**. Reprinting a PDF, recompressing a photo to save space, exporting from another program or even a plain «save as» can change the file's bytes — and verification runs on those exact bytes, not on what is displayed. The original travels as it is, unoptimised and untouched. If a lighter version is needed for comfortable reading, it goes separately and is labelled a reading copy. ## How to prepare it without spoiling it 1. **Export the whole file, not document by document** — That way each file travels with its record. 2. **Do not open and resave the originals** — Reading them changes nothing; saving them again does. 3. **Include a page on how to check it** — Half a page, with the address where anyone can verify. 4. **And number everything with an index** — Whoever receives it usually does not know your work. > [!WARNING] > The detail that buys the most credibility for the least effort: **let the recipient run the check, not you**. A screenshot from you saying everything matches is a screenshot from you. Give them the file and the way to check it, and they verify it in a minute — from then on they are not trusting anyone, they are checking. That difference is exactly what certifying is for. ## What to ask before sending it **En corto** - In what format and by what channel they want it: some will not accept links. - Whether they need something signed by you alongside the bundle. - And whether they will forward it to a third party, so you know where it ends up. > [!NOTE] > What is submitted in proceedings, in what form and under which formal requirements is decided by your lawyer — and it varies by type of proceeding. **Ask before preparing the bundle**; here we explain how to make sure what you hand over is still checkable on arrival. **Can I send it zipped?** Yes: compressing does not change the files inside. Converting them does. **What if they ask for paper?** Print it, but send the digital original too: paper cannot be verified. **Should I send the whole history?** Ask: too much also complicates, and sometimes it is unwise. ## Ejemplos **A company prepares evidence for an expert and recompresses the photos to fit an email.** - Sends the originals untouched and attaches a lighter reading copy separately → The expert verifies each photo independently, which is what had to be possible. **A folder of loose files is sent to the expert.** - Provides the evidence with its references → They can verify each item themselves. **Context about what each document is missing.** - Adds an index of what is provided → The bundle is understood without phone calls. **Files that were opened and re-saved are handed over.** - Provides the originals exactly as sealed → Verification comes out correct. **More than necessary is handed over just in case.** - Selects what belongs to the case → No unnecessary information is provided. **There is no record of what was handed over.** - Records the bundle and its date → The handover is demonstrable afterwards. --- --- id: KB-SC-020 url: https://app.codecontract.io/help/smartcheck/sealing-today-something-from-years-ago idioma: en categoria: smartcheck subcategoria: empezar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-015, KB-SC-007, KB-SC-018] citadoPor: [KB-SC-013] --- # Sealing today something from years ago _You can, and you should. But it proves you hold it like this today, not that it existed then — and that difference is everything._ **Responde a:** can I seal an old document · timestamping a five-year-old contract · proving a document dates from 2019 · certifying the old archive On discovering how sealing works, the natural reaction is to want the whole archive certified at once. The operation is simple and makes sense; what needs understanding first is exactly what gets proven, because it is not what most people expect. ## What a seal applied today proves, and what it does not | Claim | Does today's seal prove it? | What would prove it | | --- | --- | --- | | That this file said this today | Yes, beyond dispute | The seal itself | | That it does not change from today on | Yes: any change is detected | The seal itself | | That it existed five years ago | No | Whatever surrounded the document then | | That nobody touched it in between | No | Versions, emails, records from that time | > [!IMPORTANT] > The third row must be clear before sealing a whole archive: **a seal fixes the moment it is applied, and that moment is today**. If in two years you dispute a 2019 contract sealed in 2026, what you can prove is that in 2026 the file was exactly that — nothing about 2019. It is not a flaw in the seal: it is what a timestamp means, which is why the moment to seal something is when it is born, not when it becomes a problem. ## So is sealing old material worth it? **En corto** - Yes, for a practical reason: from today nobody can alter it unnoticed. - It freezes the version you consider good, which is often what gets disputed. - And in an archive many people have passed through, that is worth more than it seems. - What it does not do is fill the gap of the earlier years. ## What supports the age, since the seal cannot 1. **The email it was sent or received with back then** — With its date and sender, the commonest piece. 2. **What a third party did on the strength of it** — An invoice, a filing, a reply: that anchors the date. 3. **The intermediate versions** — An earlier draft evidences a process, not just a result. 4. **And anything not held only by you** — That is the criterion: what only you hold convinces less. > [!WARNING] > A detail that surprises people sealing old archives: **if the same document exists in two places with tiny differences, sealing both creates two official versions and neither beats the other**. Before sealing in bulk it is worth deciding which is the good one, because afterwards you hold two contradictory proofs instead of one doubt. It is the uncomfortable part of the exercise and also the most useful: it forces you to sort out what was duplicated. > [!NOTE] > What weight each kind of evidence carries and what is needed to support a date depends on the matter and the proceedings. **Your lawyer assesses that**; here we explain what a seal applied today adds and what it does not. **Can I seal a scan of an old paper?** Yes: it fixes that scan. The paper remains the source item. **Does sealing many documents at once change anything?** Not as to dates; it only saves time. **What if the document was already signed electronically?** Then its moment is already fixed: nothing more is needed. ## Ejemplos **A company seals its old archive and finds the same contract in two different wordings.** - Decides which version is the good one before sealing in bulk → It ends up with one clear proof instead of two official versions contradicting each other. **A five-year-old document is sealed today.** - Makes clear it proves how you hold it today → Nothing more is asserted than the seal says. **It is presented as proof that it existed back then.** - Accompanies it with other evidence from the period → The claim is supported by the right material. **A whole history is sealed at once.** - Seals what could end up disputed → Effort goes where it matters. **There is doubt whether sealing old material is worth it.** - Seals what still has live effects → What can still be disputed is covered. **It is sealed and nobody notes why it was done then.** - Records the reason alongside the evidence → Years later the decision is understood. --- --- id: KB-DI-003 url: https://app.codecontract.io/help/documents-and-ai/supported-formats-and-size idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-001, KB-DI-004] citadoPor: [KB-PR-005, KB-DI-007, KB-DI-008, KB-PR-015, KB-DI-017] --- # Which formats and what size _The real limits on an upload and how to work around whichever one you hit._ **Responde a:** which file formats are accepted · the file is too large · upload size limit · can i upload word or only pdf Almost any document you have will work. The limits that exist are two: the size and, for automatic reading, whether the original can be read at all. | Format | Uploads | Read automatically | | --- | --- | --- | | PDF with text | Yes | Yes, and it is the best case | | Scanned PDF | Yes | Yes, if the scan is legible | | Photo (JPG, PNG, HEIC) | Yes | Yes, if it is in focus and straight | | Word, Excel | Yes | Yes | | Archives (zip) | Yes | The documents inside are read | ## The size The per-file limit is 30 MB, which covers practically everything except scans made at print resolution. If you exceed it, it is almost always because the scanner is set to 600 dpi: dropping to 300 quarters the weight without losing anything legible. > [!WARNING] > Before uploading a scan, check it reads at a glance. What you cannot read, automatic reading cannot read either. ## What to do with a huge file - Drop the scan resolution to 300 dpi. - Scan in black and white if colour adds nothing. - Split it: usually it is several documents bundled into one. **Can I upload several at once?** Yes, by dragging the whole selection. **A 200-page PDF?** Yes, as long as it stays under 30 MB. **Is what I upload compressed?** No. It is stored exactly as it arrived, which is what lets it serve as evidence. ## Ejemplos **An accountancy firm cannot upload a 48 MB scan of a deed.** - Rescans at 300 dpi in greyscale → The same document weighs 9 MB, uploads without trouble and reads just as well. **An unsupported format is uploaded.** - Converts to an accepted format → The document goes in first time. **A file exceeds the size limit.** - Compresses or splits before uploading → It uploads without losing content. **It is compressed so much it stops being readable.** - Adjusts compression while keeping legibility → The document goes in and also reads. **A bulk load is planned without checking formats.** - Tries a sample first → The big load does not stall halfway. **An old format does not process well.** - Converts it to a standard format → The document looks the same for everyone. --- --- id: KB-DI-004 url: https://app.codecontract.io/help/documents-and-ai/why-it-sometimes-reads-wrong idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-002, KB-DI-005] citadoPor: [KB-DI-003, KB-DI-005, KB-DI-009, KB-DI-011, KB-DI-013, KB-DI-015, KB-DI-018, KB-GL-009, KB-GL-010] --- # Why it sometimes reads wrong _What makes automatic reading fail, and what you can change._ **Responde a:** the extracted data is wrong · why is the tax id read incorrectly · ocr is not reading my document · improve reading accuracy Automatic reading does not guess: it recognises. When it fails it is almost always because there was nothing recognisable in the original, and that is something you can fix before uploading. **En corto** - A text PDF reads almost perfectly; a crooked photo does not. - The confidence indicator tells you when to look. - Correcting a field teaches the system for that document type. ## The five causes, by frequency | Cause | What you see | Fix | | --- | --- | --- | | Crooked or shadowed photo | Half-read or invented values | Retake it with the paper flat on a table, in good light | | Low-resolution scan | Confuses 8 with B, 0 with O | Rescan at 300 dpi | | Handwritten document | Very low confidence | Manual review: that is expected | | Unusual layout | Picks up some fields, not others | Correct once; it improves for the next ones | | Several documents in one PDF | Mixes data from two | Split them before uploading | ## The confidence indicator Every extracted value carries a note of how sure it is. High means you can use it without looking; medium, worth a glance; low, must be checked. It is not decoration: it is the difference between reviewing everything and reviewing 10%. > [!IMPORTANT] > Never use a low-confidence value for anything with consequences — a payment, an official registration — without looking at it. Automatic reading saves time, not responsibility. **Does it learn from my corrections?** Yes, for that document type within your organisation. **Can I turn reading off?** Yes. The document is stored just the same, only without extracted data. **How long does it take?** Seconds for a normal document; a little longer for a hundred-page one. ## Ejemplos **Tax IDs from one supplier's certificates come out wrong again and again.** - Looks at the original: they are hand-held photos with shadow - Asks for scans instead → From then on confidence is high and they stop being checked one by one. **The document is scanned at low quality.** - Rescans at a better resolution → Reading improves without touching anything else. **The text sits on a patterned background.** - Reviews by hand whatever is flagged → You correct the little that fails. **The document's text is an image inside a PDF.** - Checks it was processed as an image → The text becomes searchable. **A stamp covers part of a figure.** - Corrects the figure by checking the image → The figure ends up right even though the paper made it hard. **One document type always fails the same way.** - Checks whether the model fits that format → The problem is tackled at source. --- --- id: KB-DI-005 url: https://app.codecontract.io/help/documents-and-ai/correcting-a-misread-value idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-TZ-001] citadoPor: [KB-DI-004, KB-DI-006, KB-DI-016, KB-MA-020, KB-GL-010, KB-CF-002] --- # Correcting a misread value _How to correct it, what happens to the original, and why it is worth doing._ **Responde a:** change a value extracted from a document · correct the read expiry date · edit a document's data · who changed this value Correcting a value takes five seconds and does two things: it makes the value right now, and it may make the next similar document read better. ## How to do it 1. **Open the document.** 2. **Click the misread value.** 3. **Type the correct one.** ## What happens to the previous value **En corto** - The original document is never touched. You correct the reading, not the paper. - The old value, the new one, who changed it and when are all kept. - If the value drove an alert — an expiry, say — it is recalculated automatically. > [!NOTE] > Keeping the old value is not bureaucracy: if anyone asks why the system said something different in March, the answer is right there. > [!WARNING] > Correcting a value does not correct the document. If the paper itself is wrong — a certificate with the wrong tax ID — you need a new one, not a tidied-up field. **Can I correct several at once?** Yes, in the batch review view. **Can I go back to the original value?** Yes, what the system read is kept. **Does it count as a new version?** The value does; the document does not, because it has not changed. ## Ejemplos **An insurance policy is read as expiring in 2027 when the paper says 2026.** - Corrects the date → The renewal alert repositions itself, and the gap is not discovered during an inspection. **A figure is corrected and people think the document changes.** - Checks the document is unchanged → The evidence stays intact. **It is corrected and nobody knows it changed.** - Checks the figure's history → The correction has an author and a date. **The same error repeats across many documents.** - Checks whether the format is the cause → The cause is fixed rather than each case. **A figure that feeds a warning is corrected.** - Checks the warning recalculates → The warning becomes true again. **It is corrected without looking at the original image.** - Compares with the document before saving → The correction is right. --- --- id: KB-DI-006 url: https://app.codecontract.io/help/documents-and-ai/document-versions idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-005, KB-TZ-002] citadoPor: [KB-DI-010, KB-PR-012] --- # When a new version arrives _Replace without losing the previous one, and know which was valid when._ **Responde a:** upload a new version of a document · the supplier sends the renewed insurance · view previous versions of a file · replace a document without deleting it Insurance renews, a certificate is reissued, a contract gets an amendment. The natural move would be to delete the old and put up the new, and that is precisely what not to do: the old one is what proves what was valid last year. **En corto** - The new version becomes current; the previous one sits beneath it. - Each version keeps its delivery date and who sent it. - Expiry warnings recalculate against the new one. ## How it works 1. **Upload the new document in the same place, not as a separate one.** 2. **It becomes the current version automatically.** 3. **The previous one stays viewable, marked as superseded.** ## Why keeping the previous one matters | Question that arrives | What answers it | | --- | --- | | Were they insured in March? | The version current in March, not today's | | When was it renewed? | Each version's delivery date | | Did anything change between them? | Both, side by side | > [!IMPORTANT] > Uploading a renewal as a separate new document instead of a version is the mistake that most clutters a case: you end up with six loose insurance policies and no idea which was valid on which date. > [!WARNING] > Replacing is not the same as correcting a misread value. If the document is fine and what is wrong is what was extracted, correct the value; do not ask for another document. **Can I go back to a previous version?** You can view and download it; the current one changes by uploading whichever should be. **How many versions are kept?** All of them, within your retention policy. **Is anyone notified when a version is uploaded?** Whoever has to approve it, if that request required approval. ## Ejemplos **A supplier has sent renewed insurance every January for four years.** - Each one is uploaded as a version over the previous → Faced with a 2024 claim, they can show exactly the policy in force on that day. **A new version arrives and replaces the previous one.** - Keeps both with their dates → You can say what applied at each moment. **Nobody knows what changed from the previous version.** - Compares the two versions → The change is visible without reading it through. **Work continues on the old version.** - Marks which one is current → The team uses the right one. **A client asks for the version they were given.** - Checks which version covered that delivery → The right one is provided. **The new version arrives and nobody tells its users.** - Notifies whoever has the previous one assigned → The change reaches whoever it affects. --- --- id: KB-DI-007 url: https://app.codecontract.io/help/documents-and-ai/scanning-a-document-properly idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-003, KB-PR-005] citadoPor: [KB-DI-008, KB-DI-012, KB-DI-015] --- # Scanning a document properly _Five minutes of method that avoid half the reading problems._ **Responde a:** how to scan a document so it reads well · what dpi to scan at · photograph a document with a phone · the scan is too large The quality of the original decides almost everything that follows: whether it reads well, whether you can search inside it, whether it has to be reviewed by hand. And fixing it costs five minutes at scanning time, against hours of review afterwards. ## The numbers that work | Setting | Value | Why | | --- | --- | --- | | Resolution | 300 dpi | Enough to read; 600 weighs four times as much and gains nothing | | Colour | Greyscale | Unless colour means something, such as a stamp | | Format | PDF | Better than loose images: it keeps the page order | ## If you use a phone **En corto** - Lay the paper on a table, do not hold it. - Light in front of you, not behind: your own shadow is the commonest cause of a bad result. - Frame the whole page, straight, with no fingers or table edges. A current phone in decent light matches a scanner. What ruins photos is not the camera, it is hurry. > [!WARNING] > If the paper is creased or the print is very faint, no scan will fix it. What is needed there is another original. > [!NOTE] > A document that already exists digitally should not be scanned: ask for the PDF. Scanning a printout of a PDF loses the text it already contained, which then has to be recognised by OCR. **What about fifty pages?** In one PDF, not fifty images. **Is scanning in colour worth it?** Only if colour adds something: a stamp, a blue signature, a chart. **Can I crop the photo?** Yes, to remove the table. Do not retouch anything else if the document may serve as evidence. ## Ejemplos **A supplier's certificates read badly again and again.** - The original is checked: hand-held photos with shadow - This guidance is sent to them → From the next send onward reading comes back high-confidence and manual review stops. **The scan comes out dark and cannot be read.** - Redoes it with more light and no shadows → Reading works first time. **It is scanned at very low resolution to keep it small.** - Raises the resolution without exceeding the limit → The document goes in and also reads. **The document comes out cropped at the edges.** - Frames the whole document → No text is missing from the reading. **Black text is scanned in colour.** - Scans in whichever mode gives the best contrast → The file is smaller and reads better. **Each person scans differently.** - Agrees common settings → Quality stops depending on who scans. --- --- id: KB-DI-008 url: https://app.codecontract.io/help/documents-and-ai/uploading-your-first-document idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-003, KB-DI-007, KB-DI-019] citadoPor: [KB-DI-017] --- # Uploading your first document _What happens when you drop it in, and what to decide next._ **Responde a:** how do i upload a document · drag files into the platform · what happens when i upload a pdf · where are my documents stored Uploading is dragging the file in. What is interesting starts afterwards, because what happens next decides whether that document will be useful or just another copy in a new place. ## What happens when you drop it 1. **It is stored as is** — Encrypted and untouched. The original is never modified: that is what lets it serve as evidence. 2. **It is read, if that type has reading enabled** — The values that matter are extracted: dates, amounts, identifiers. 3. **It becomes searchable by content** — Not only by filename, which is how almost nobody looks for it. ## What to decide right then | Decision | Why now | | --- | --- | | If it expires, set the date | It is when you have it in front of you. Nobody looks at it again later | | Where it goes | By client, site or project: by whatever people ask about | | Who should see it | Especially if it carries personal data | > [!NOTE] > The expiry date is what turns a file into something that warns you. A document without one is stored paper; with one, it is an alert eleven months from now. > [!WARNING] > Before uploading something with another person's data — an ID document, a payslip, a medical report — consider whether you genuinely need to keep it. What is not stored cannot be lost. **Up to what size?** 30 MB per file, which covers practically everything. **Can I upload several at once?** Yes, by dragging a selection or a whole folder. **Can it be replaced with a new version?** Yes, and the previous one is kept with its date. ## Ejemplos **Someone uploads their twenty suppliers' insurance policies without setting dates.** - Goes back and marks each one's expiry → Eleven months later twenty warnings arrive by themselves, instead of it surfacing during an inspection. **The first document is uploaded without knowing where it goes.** - Picks the file before uploading → The document lands where it will be looked for. **It is uploaded and nobody knows whether it was read.** - Checks whether extracted data appears → You know what the system did. **A confidential document is used for the trial.** - Uses a test one the first time → Learning compromises nothing. **It is uploaded and the tab closed before it finishes.** - Waits until it appears in the list → The upload is confirmed. **The worst scan available is used for the test.** - That is exactly what is worth testing first → You know the worst case before deciding. --- --- id: KB-DI-009 url: https://app.codecontract.io/help/documents-and-ai/which-values-are-worth-extracting idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-GL-010] citadoPor: [KB-DI-011, KB-TD-019, KB-DI-020] --- # Which values are worth extracting _Extracting too much creates review work and returns nothing._ **Responde a:** which fields to configure for extraction · field map for a document type · extracting too many values · configure reading per document type The temptation when configuring a document type is to tick everything that appears on the paper. It is an expensive mistake: every extracted value is one someone will have to review when it comes back low-confidence, and most will never be used. ## The question that decides For each field: **will I filter, alert or decide with this?** If the answer is no, do not extract it. The document is still stored whole and searchable by content; extracting a value is something else. | Value | Extract it? | Why | | --- | --- | --- | | Expiry date | Always | It is what fires the alert | | Tax identifier | Yes | It lets you cross-reference with your system | | Insured amount | If you require a minimum | If you never check it, it serves nothing | | Insurer name | Rarely | You do not filter on it | | Full address | Almost never | It is in the document if needed | > [!IMPORTANT] > Extracting personal data you will not use is storing it twice: in the document and as a loose value. If you do not need it to filter or alert, do not extract it — it is the practical application of asking for the minimum. ## The sign you overdid it - Nobody reviews the low-confidence alerts because there are too many. - There are fields nobody has looked at in months. - People correct values that change no decision. > [!NOTE] > Start with two or three fields per type. Adding one later takes a minute; unlearning the habit of reviewing forty useless fields takes considerably longer. **Can I change the fields on a type already in use?** Yes. What was already extracted is kept. **Can values be extracted without anyone reviewing?** Yes, if the value fires nothing critical. Review is reserved for what decides something. **What if the document does not carry the value?** It stays empty. That is information: it means that document does not serve what you wanted. ## Ejemplos **A company configures fourteen fields per certificate and nobody reviews the alerts any more.** - Keeps three: expiry, tax identifier and insured amount → Low-confidence alerts drop to a handful and get looked at again. **Twenty fields are extracted and only three are used.** - Extracts what somebody will actually consult → Review narrows to the useful. **A search is made on a field nobody extracted.** - Adds that field to the extraction → Search finds what is needed. **Fields already held elsewhere are extracted.** - Checks whether the figure already exists → Information is not duplicated. **A warning depends on a date that is not extracted.** - Extracts the validity date → The warning works. **Each document type is configured differently.** - Defines what to extract per type → Documents of the same type are comparable. --- --- id: KB-DI-010 url: https://app.codecontract.io/help/documents-and-ai/deleting-a-document-or-not idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-006, KB-TZ-003] citadoPor: [KB-PR-014, KB-DI-019, KB-AD-020] --- # Deleting a document, or not _What can be deleted, what should be, and what must not._ **Responde a:** how do i delete a document uploaded by mistake · can i remove a file · remove a document from a case · recover a deleted document Deleting looks like the obvious fix when something is wrong, and it almost never is. Before doing it, work out which of the three cases you are in, because only one of them calls for deletion. | Situation | What to do | Why | | --- | --- | --- | | You uploaded the wrong file | Delete it and upload the right one | It proves nothing and should not be there | | The document is expired or superseded | Upload the new version over it | The previous one shows what was valid then | | The extracted value is wrong, the paper is right | Correct the value, leave the document alone | There is nothing wrong with the document | ## What must not be deleted - Anything connected to an open claim or litigation. - Documents that are part of a signature: the signature covers them. - Whatever you are obliged to retain, even if you no longer need it. > [!IMPORTANT] > If there are open proceedings touching a document, do not delete it even if it seems irrelevant. Every deletion is logged with its date, and one made after a claim starts always reads in the worst possible way, however innocent. ## What is worth deleting What you should not hold: ID copies requested without needing them, personal data from processes that ended years ago, third-party documents that arrived by mistake. Keeping too much is not prudence, it is accumulated risk. > [!WARNING] > Before deleting something someone else uploaded, ask them. It may be there for a reason you cannot see, and recovery is not always possible. > [!NOTE] > If you hesitate between deleting and keeping, ask whether the document proves anything. The ones that prove stay; the ones that merely occupy space go. **Can deleted items be recovered?** It depends on your retention settings. Do not count on it. **Is there a record of who deleted it?** Yes, with the date. **Does deleting free space or credits?** Credits already consumed do not come back. ## Ejemplos **Someone wants to delete a supplier's old insurance policies "to tidy up".** - Checks they prove each year's cover - Keeps them as previous versions → Months later a two-year-old claim is closed by showing the policy in force on that day. **A document is deleted and disappears from a file.** - Checks where it is referenced before deleting → Deleting breaks nothing. **A duplicate is deleted and it was the good one.** - Checks which one sits in the right file → The useful one remains. **Something that had to be retained is deleted.** - Checks the policy before deleting → Deleting stops being a gamble. **Deletion happens and there is no record of it.** - Records what was deleted and when → What was done is demonstrable. **It is archived rather than deleted and lost from view.** - Decides between archiving and deleting per case → The archive stays readable. --- --- id: KB-DI-011 url: https://app.codecontract.io/help/documents-and-ai/very-long-documents idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-DI-009] citadoPor: [KB-DI-013] --- # Very long documents _Two hundred pages of which four values matter. How to approach it._ **Responde a:** extract data from a very long pdf · document with hundreds of pages · reading a full tender document · pulling information from a long contract A tender pack, a policy or a framework contract can run to two hundred pages. Of all of them, what you need usually fits on half a page: four dates, two amounts and three conditions. The problem is not reading it, it is not having to read it again every time someone asks. ## What changes versus a short document | Aspect | Short document | Long document | | --- | --- | --- | | The reading | Straightforward | The same, just slower | | What gets extracted | Almost everything relevant | Only the fields you choose | | The risk | One value misread | A correct value from the wrong place | | The review | Read it in full | Check field by field | > [!IMPORTANT] > The third row is what is specific to long documents. Two hundred pages hold many dates and many amounts; the typical error is not misreading a number, it is taking the correct number from the wrong clause. ## How to approach it 1. **Decide beforehand which four or five values matter** — If the list runs to twenty, reviewing will take as long as reading. 2. **Check each value against its place in the document** — A plausible value is not enough: it must come from the right clause. 3. **Keep it linked to the file, not loose** — The document lives where it is used; the data, where it is consulted. 4. **And note the doubt if there is one** — An ambiguous condition is not resolved by extracting it: flag it for someone to read. > [!WARNING] > Do not use an automatic summary to take a contractual decision. It helps you orient and know which clause to open; what binds you is the text, not the summary. ## When the document is also scanned A two-hundred-page tender scanned at poor quality is the worst case: a lot of text and little reliability. If it is an important document that will be consulted for years, it pays to obtain the electronic original rather than to fix the scan's reading. **En corto** - Few fields, well checked, beat many unreviewed. - The right value has to come from the right place. - And what is ambiguous gets flagged, not extracted. > [!NOTE] > Upload size limits are the same as for any document. If a file will not fit, it is almost always because it was scanned at a far higher resolution than needed, not because it has too many pages. **Does it take much longer?** Longer than a short one, yes. Not a problem if you upload it when it arrives rather than when you need it. **Can I search inside it afterwards?** Yes, and that is half the value: finding the clause without going through it all. **What if only three pages interest me?** Upload the whole document and extract only from those: the rest stays there just in case. ## Ejemplos **A company wins a 180-page framework contract and every query means rereading it.** - Extracts six key values and checks each against its clause - Keeps the document linked to the client file → Queries are answered on the spot and the contract is only opened when the text must be quoted. **A two-hundred-page document takes a while to process.** - Leaves the process running and moves on → Processing time blocks nobody. **Only one figure is needed from a very long document.** - Extracts only the fields that will be used → Review narrows to the useful. **The document exceeds the size limit.** - Splits it into meaningful parts → Each part goes in and is locatable. **Searching inside the document by hand is impossible.** - Searches by content within the document → You reach the exact point. **The whole thing is uploaded when only two annexes mattered.** - Uploads what will be consulted → The archive does not grow without reason. --- --- id: KB-DI-012 url: https://app.codecontract.io/help/documents-and-ai/photos-taken-on-a-phone-at-work idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-007, KB-DI-002] citadoPor: [KB-DI-014, KB-CF-019] --- # Photos taken on a phone at work _The delivery note, the meter, the damage, the plate: when a photo is a document and when it is a memento._ **Responde a:** upload phone photos to a file · photographing a delivery note instead of scanning · do phone photos count as documents · taking site photos so they are not lost Most field documentation is born as a phone photo: the signed delivery note, a meter reading, damage to goods, the state of an installation. The problem is not photo quality: it is that it stays in one person's camera roll. ## When a photo is a document | It is a document when… | It is just a photo when… | | --- | --- | | It is in the file it belongs to | It is in someone's gallery | | You know who took it and when | It only has the phone's metadata | | It can be found by what it shows | It is called IMG_4821 | | And someone else can see it | Only the person who took it has it | > [!IMPORTANT] > The fourth decides. A photo that exists only on a phone is lost with that phone, and lost with that person when they change jobs. The work happened, but no evidence remains. ## How to make them count 1. **Upload it at the moment, from the phone** — To the right file. Ten seconds then are worth more than half an hour later. 2. **Have it read, if it contains text** — A photographed and read delivery note is searchable by number or supplier; unread, it is not. 3. **Frame the whole document** — The commonest failure: cropping an edge and losing the stamp, date or signature. 4. **And certify what could end in dispute** — Damage, delivery condition, readings. A provable date is worth a lot there. > [!WARNING] > The angled photo with a shadow across it is the hardest to read, and it is usually the delivery note you will need in six months. Straight on, well lit, without your own shadow: that is half the result. ## What is always worth photographing **En corto** - Anything signed on paper because there was no alternative. - The state of something before and after handling it. - Readings, meters and rating plates. - And anything handed to you in person that will not arrive another way. > [!NOTE] > If there is no signal, take the photo anyway and upload on the way out. What does not work is leaving the upload for the office: that is where it gets lost. **Do phone photos take much space?** Less than a maximum-resolution scan, and well within the upload limit. **Can I upload several at once?** Yes, and for a day in the field that is normal. **Does a photo count as evidence?** It depends what accompanies it: provable date, author and context. A photo alone is worth little. ## Ejemplos **A technician keeps photos of every job on his phone.** - Uploads them to each job's file at the moment → When a client complains six months later, the photo is where it should be, with a date. **The photo is taken holding the document and comes out blurred.** - Rests the document before shooting → Reading works first time. **The photo is taken against the light in a warehouse.** - Moves to find even lighting → The text comes out legible. **The photos stay in the phone's camera roll.** - Uploads them to the file at the moment → The record does not depend on the handset. **Photos are taken in a rush and a page is missing.** - Checks all of them are there before leaving → No return trip is needed. **The photo is large and the upload fails.** - Uploads on a stable connection or reduces the size → The upload completes. --- --- id: KB-DI-013 url: https://app.codecontract.io/help/documents-and-ai/documents-in-another-language idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-CC-007, KB-DI-011, KB-DI-015, KB-DI-018] citadoPor: [KB-DI-021] --- # Documents in another language _A certificate in German, an invoice in Chinese: what can be done and what should be translated._ **Responde a:** document in another language what do i do · reading a foreign certificate · when a sworn translation is needed · extracting data from a foreign-language invoice As soon as you buy or sell abroad, documents start arriving in languages nobody on the team reads. The typical reaction — translate everything — is expensive and unnecessary; the opposite — file it without understanding it — is worse. ## Three different things that get confused | Need | What it solves | When it is needed | | --- | --- | --- | | Understanding what it says | Knowing whether it serves and what data it holds | Almost always | | Being able to find it later | Locating it by its content | Almost always | | Sworn translation | Official standing before an authority | Only when someone specific requires it | > [!IMPORTANT] > The first two are solved by reading the document on upload: data is extracted the same way, and search works on what it says, whatever the language. The third is a legal formality that costs money: request it only when someone requires it, in writing. ## What to do on receipt 1. **Upload it as it is, without waiting for translation** — The original is the document; the translation is an addition. 2. **Extract the values you care about** — Dates, amounts, identifiers. They rarely depend on language. 3. **Note in your language what it is** — One line is enough: "conformity certificate from supplier X, valid until…". 4. **And if a translation is needed, link it to the original** — Both together; a loose translation loses its reference. > [!WARNING] > Watch dates and numbers. Formats vary by country: the same document can read as 3 June or 6 March, and thousand and decimal separators swap. It is the costliest and quietest error. ## When a sworn translation really is needed **En corto** - When an authority or a court requires it. - When the contract expressly demands it. - And when the document will support a claim in another country. Otherwise, understanding the document and being able to find it is all you need, and that requires translating nothing. > [!NOTE] > If you send requests to suppliers abroad, sending them in their language changes response rates considerably. And what comes back will still be in their language: that is normal and does not stop you working with it. **Are non-Latin scripts read?** Yes, though quality depends heavily on the scan. **Is machine translation enough to decide?** To orient yourself yes; for a decision with consequences, verify. **What if nobody on the team understands it?** Note in your language what it is and who it is from: that alone prevents 90% of problems. ## Ejemplos **A company piles up Asian supplier certificates, untranslated and unuploaded.** - Uploads them as they are and extracts dates and identifiers - Notes in English what each one is → It can find them and know when they expire without paying for a single translation. **A document arrives in a language nobody reads.** - Extracts the fields that are needed → The document is usable without translating it all. **It is fully translated when three fields would have done.** - Translates only what needs understanding → The cost matches the need. **A client asks for the document in their language.** - Asks whether an official translation is needed → You translate what is appropriate. **The supplier always sends in their own language.** - Agrees the language on the order → It arrives usable from the first shipment. **It is filed without knowing what it says.** - Notes what the document is when filing it → It is located later without opening it. --- --- id: KB-DI-014 url: https://app.codecontract.io/help/documents-and-ai/documents-that-arrive-by-messaging idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-012, KB-CC-001, KB-DI-017] citadoPor: [KB-DI-019] --- # Documents that arrive by messaging _The delivery note someone sends you on WhatsApp exists, and you must decide what to do with it._ **Responde a:** they send me documents on whatsapp · documents via instant messaging · saving a pdf received in a chat · the supplier sends photos on whatsapp Like it or not, a lot of real documentation now arrives by messaging: the photographed delivery note, the PDF certificate, the photo of damage. Banning it does not work — people will keep doing it — and accepting it as is leaves company documentation on someone's personal phone. ## The three problems with leaving it there | Problem | Consequence | | --- | --- | | It is on a personal phone | It leaves with the person and the phone | | There is no context | A loose PDF in a chat does not say which order it belongs to | | There is no useful record | "I sent it on WhatsApp" is not a delivery record | > [!IMPORTANT] > The third causes the most arguments. Messaging shows a file was sent, but that evidence lives on two private phones and is easy to lose or dispute. It is not the same as a recorded send. ## What to do, without falling out with anyone 1. **Accept it as a notification route, not a delivery route** — "Great, now upload it here" turns a chat into documentation. 2. **If it already arrived that way, upload it yourselves** — Ten seconds. Better than losing it on principle. 3. **And for anything that matters, ask via the recorded route** — Signatures, formal submissions, deadlines. Messaging is not enough there. > [!WARNING] > The dangerous case is signing. An "agreed" in a chat may count as an indication, but it does not leave the evidence a signature does: identity, moment and exact content accepted. That is what a signature request is for, and it costs the same as arguing afterwards. ## When messaging is the right channel **En corto** - To say that something has been uploaded. - To unblock someone who does not open email. - And for a quick photo that is then stored where it belongs. Used that way it is an excellent channel: it arrives, it gets read, it unblocks. The problem was never the channel, it was using it as an archive. > [!NOTE] > If you send requests through that channel, the recipient can still supply via the link, with nothing to install. That is how to benefit from messaging's reach without losing the record. **Can reminders be sent there?** Yes, and for some recipients it works considerably better than email. **Is a delivery note photo sent by chat valid?** As a document yes, if you upload it. As proof of delivery, no. **What about site or team groups?** They are good for coordinating; whatever is decided there, if it matters, goes into the file. ## Ejemplos **A site manager receives every delivery note by chat and keeps them on his phone.** - Uploads each to the site's file on receipt → Changing phones loses nothing and delivery notes can be searched by supplier. **The document arrives on paper by courier.** - Captures it on receipt → It enters the file the same day. **The envelope is opened and the paper sits in a tray.** - Digitises at reception itself → There stops being a pile waiting. **Nobody knows whether a document came by post or courier.** - Records the entry route → The history reflects what happened. **The original must be kept as well as the copy.** - Notes where the original is stored → It is located without walking the archive. **Something arrives that belongs to no file.** - Records it and finds who it belongs to → It does not sit in an ownerless tray. --- --- id: KB-DI-015 url: https://app.codecontract.io/help/documents-and-ai/handwritten-documents idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-DI-007, KB-DI-020] citadoPor: [KB-DI-013] --- # Handwritten documents _Job sheets, delivery notes and pen annotations: what can be extracted and what is better typed._ **Responde a:** reading a handwritten document · ocr cannot read handwriting · delivery note filled in by hand · digitising paper job sheets Much of the paper still circulating is filled in by hand: the delivery note with the corrected quantity, the technician's job sheet, the control log with the shift's temperatures. It can and should be uploaded, but it helps to know what to expect from it. ## What reads well and what does not | Element | Reads | Comment | | --- | --- | --- | | The pre-printed form | Well | Printed text is ordinary text | | Clear, separated digits | So-so | A 1 and a 7 blur depending on the writer | | Running handwriting | Badly | Real handwriting is not the textbook kind | | Signatures and scrawls | Not text | They are visible, but say nothing by themselves | > [!IMPORTANT] > The nuance you cannot deduce from the screen: when handwriting reads badly, the result **usually comes back wrong rather than empty**. A scanned form returns the printed text perfectly and, in the handwritten box, a plausible value that may not be what is written. That is more dangerous than reading nothing, because it looks right. ## How to work with them without losing time 1. **Upload them anyway, always** — Even with imperfect reading, the document is stored, dated and findable through its matter. 2. **Type the two or three values that matter** — Quantity, date, batch number. Thirty seconds that prevent a claim. 3. **Check figures before using them** — If a handwritten value feeds an invoice or a mandatory record, check it against the image. 4. **And photograph straight on and well lit** — With handwriting, scan quality changes the outcome more than in any other case. > [!WARNING] > Beware pen corrections on a printed form: a crossed-out quantity rewritten beside it reads as two numbers, and not always the right one wins. When paper arrives corrected, that value gets typed, not inherited. ## What is worth changing at source **En corto** - If your own team fills in the sheet, signing on a phone removes the handwriting entirely. - If a third party fills it in, asking for the form digitally is easier than it sounds. - And if paper is unavoidable, at least put key fields in separate boxes. That last point is free and changes a lot: a number written inside a box reads considerably better than the same number on an open line. > [!NOTE] > A badly read handwritten document is not a lost document: it is still there, still visible and still evidence of what it said. All it loses is content search, and that is offset by typing the few values you actually consult. **Can it be reprocessed if reading improves?** Yes, and it does not need re-uploading. **Does it work for field logbooks or registers?** As an archive yes; to answer quickly, type the values you will be asked about. **What if the document is old with no digital original?** That is exactly the case for uploading it and noting the essentials by hand. ## Ejemplos **A warehouse uploads delivery notes with quantities corrected in pen and invoices from the read value.** - Types the final quantity after checking the image - Asks the supplier for digital notes → Quantity differences stop appearing in the month's invoices. **A handwritten document reads only partially.** - Reviews by hand whatever is flagged → You correct the little that fails. **The handwriting is difficult and everything is retyped.** - Uses what did come out and corrects the rest → Keying is reduced. **A manuscript is photographed in poor light.** - Redoes it with better light and contrast → Reading improves considerably. **A handwritten form repeats every week.** - Considers replacing it with direct capture → The problem disappears at source. **What was read is approved without checking the manuscript.** - Compares with the image before approving → The stored figure is what the paper says. --- --- id: KB-DI-016 url: https://app.codecontract.io/help/documents-and-ai/the-same-value-appearing-twice-differently idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-005, KB-IC-012] citadoPor: [KB-GL-016, KB-DI-018, KB-DI-020] --- # The same value appearing twice differently _The invoice says one thing and the delivery note another. Which wins and what to do with the gap._ **Responde a:** invoice and delivery note do not match · conflicting data between documents · which document wins when they differ · reconciling quantities across documents When two documents about the same matter say different things, the problem is not reading: both were read correctly and they disagree with each other. It is a real discrepancy, and the only change is that you now see it the same day instead of at month end. ## Why they differ, by frequency | Cause | How to recognise it | What to do | | --- | --- | --- | | What was delivered differs from what was ordered | The delivery note matches what arrived, not the order | Accept or claim, but decide | | A handwritten correction on the paper | A crossed-out figure with another beside it | The corrected one stands, and gets typed | | Documents from different dates | One partial delivery and a later one | Not a discrepancy: two separate facts | | An error by the issuer | The other values do not fit either | Ask for a corrected document | > [!IMPORTANT] > The third row generates false alarms and wastes the most time. Before claiming anything, check the dates: two documents that disagree because they describe different moments are not an error, they are the normal story of a split delivery. ## Which document wins 1. **For what was delivered, the signed delivery note** — It records what actually arrived and who received it. 2. **For what was ordered, the order** — The gap between the two is exactly what needs clarifying. 3. **For what is charged, the invoice** — And it should match the delivery note, not the order. 4. **And if there is a contract, the contract wins** — Prices, terms and agreed tolerances live there, not in delivery notes. > [!WARNING] > The nuance you only learn by living it: **the extracted value does not replace the document**. If you are going to claim over a difference, the claim rests on the image of the delivery note with its number and signature, not on the figure in a listing. The listing is for spotting the difference in the moment; the evidence is still the document. ## How to catch it before paying **En corto** - By cross-checking what was extracted from delivery note and invoice against the same order. - With a decided tolerance: not every mismatch deserves a phone call. - And by asking whoever receives, not whoever pays: the person at the unloading knows what arrived. That last point saves more arguments than any tool: accounts sees paper and the warehouse saw the goods. When the doubt is settled by asking whoever unloaded, it closes in a minute. > [!NOTE] > Cross-checking values between two documents is an AI action and consumes, like any other. It pays where there is money or risk — goods-in, large invoices, critical batches — rather than across the whole flow as a matter of course. **Can I correct the extracted value by hand?** Yes, and it helps: there is then a record that someone reviewed it. **What if the supplier does not accept the difference?** That is where the signed delivery note earns its keep. **Can it alert automatically when they disagree?** Yes, and it is among the highest-yield rules if you give it a sensible tolerance. ## Ejemplos **Accounts finds at month end that three invoices do not match their delivery notes.** - Cross-checks note and invoice on receipt, with an agreed tolerance - Asks whoever unloaded before claiming → Differences get resolved the same day and stop turning up at closing. **The same figure appears with two values in two documents.** - Checks which document each came from → You know what backs each value. **One of the two is chosen with no record.** - Records which is taken and why → The decision is explicable. **One document is more recent than the other.** - Compares both dates → The criterion stops being a hunch. **The misread value is corrected in the wrong place.** - Corrects it in the document it came from → Source and figure match again. **A report uses the wrong value.** - Checks where it takes the figure from → The report rests on the right one. --- --- id: KB-DI-017 url: https://app.codecontract.io/help/documents-and-ai/uploading-many-documents-at-once idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-003, KB-PS-006, KB-DI-008] citadoPor: [KB-DI-014] --- # Uploading many documents at once _What to decide before dragging in two hundred files, because undoing it afterwards costs more._ **Responde a:** upload many files at once · import a folder of documents · bulk document upload · how many documents can i upload at once Sooner or later a big block has to go in: a folder from a finished site, the archive of an incoming client, a history being migrated. It can be done, and the result depends almost entirely on three decisions taken before you start, not during. ## The three decisions 1. **Which file each item goes to** — Dropping two hundred files into a generic place is fast and creates a problem you already know: a drawer. 2. **What gets read and what does not** — Not everything deserves extraction. What will be consulted by content, yes; the rest can stay as archive. 3. **And what to do with duplicates** — In a large block there always are: the same document under two names, or two versions of one. > [!IMPORTANT] > The second changes the cost most and is the one nobody decides: **every document that is read is an action**. Uploading a two-thousand-file archive and asking for all of it to be read consumes two thousand times, and of those two thousand perhaps fifty will ever be consulted. Reading what will be used and leaving the rest as archive is the difference between bringing your history over and paying to bring it twice. ## What to check before dragging | Check | Why beforehand | | --- | --- | | That names say something | Afterwards they are already in with IMG_4821 as the title | | That there are no protected files | They upload, but cannot be read or searched | | That the block belongs to one matter | Mixing two sites in one batch is what creates the drawer | | And that someone will review what comes in | A bulk upload with no review is archiving, not management | > [!WARNING] > The practical nuance that saves an afternoon: **upload a small sample first**. Twenty files of the same type tell you whether the scan quality works, whether the names make sense and whether extraction picks up what you care about. If something is off, fixing it with twenty takes minutes; discovering it with two thousand already in does not. ## After uploading **En corto** - Review a random sample, not the first in the list. - Check that what you wanted is findable, searching the way you really would. - And note what was brought over and from where, so you do not bring it again next year. The last looks obvious and is the most repeated error in long migrations: the same folder gets brought over twice because nobody noted that it already was. > [!NOTE] > If the block is very large, split it into batches by matter rather than by size. Ten batches of twenty documents from one site each are manageable; one batch of two hundred from ten different sites is a problem to unpick by hand. **Is there a per-file limit?** Yes, and it is usually generous: if a file will not fit, it is almost always scanned at far higher resolution than needed. **Can I upload whole folders?** It depends how you do it; what matters is which file they land in, not how many there are. **What if I put the whole block in the wrong file?** Move it, do not delete: moving keeps the trail and does not consume again. ## Ejemplos **A company migrates a finished site's archive and asks for everything to be read.** - Uploads a sample of twenty before the two thousand - Decides which types get read and which stay as archive → The history comes in tidy and consumption stays on what will actually be consulted. **Three hundred documents are uploaded and nobody knows which failed.** - Checks the load's result → Only what failed gets retried. **The load cuts out halfway.** - Checks what went in before repeating → What is already uploaded is not duplicated. **They all land in the same file undifferentiated.** - Prepares the mapping before loading → Each document reaches its place. **They are loaded with names that say nothing.** - Names or classifies before uploading → They are locatable afterwards. **A big load runs without a prior test.** - Tries a small batch → The problem is found with ten rather than three hundred. --- --- id: KB-DI-018 url: https://app.codecontract.io/help/documents-and-ai/documents-with-tables idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-DI-016] citadoPor: [KB-DI-013] --- # Documents with tables _A single field almost always reads fine. A table fails elsewhere: not on the number, but on the row._ **Responde a:** reads invoice tables badly · extracting delivery note lines · why does it pick the wrong row · documents with many columns A certificate has a number, a date and a holder: three loose fields, and they read fine. An invoice, a delivery note or a results listing have twenty rows of four columns, and there automatic reading behaves differently — not worse in the way you would expect. ## Where it actually fails | What people fear | What actually happens | | --- | --- | | That it misreads the number | The number usually reads fine: the digits are large and clean | | That it skips a row | It happens, and it is visible: the total does not add up | | — | What really fails is which row each value belongs to | | — | And rows continuing onto the next page, which get split | > [!IMPORTANT] > That third point cannot be spotted by looking at the result: **a correctly read value can end up in the wrong row**, and then everything checks out separately while the whole thing lies. The sum works, every number exists in the document, and yet one reference's quantity has landed on the next one. When the breakdown matters and not just the total, check two or three random rows, not the total. ## What makes a table read well **En corto** - Table lines actually drawn, not columns separated by spaces alone. - No cell spanning two lines of text: that is what shifts the rows. - The header repeated if the table runs onto another page. - And the document coming from the system that issued it, not photographed. > [!WARNING] > If you define the table and a supplier fills it in, there is a far better way out than tuning the reading: **ask for the same data in a form rather than inside a document**. A scanned delivery note has to be read; a form with one line per reference does not. It takes the same time to fill in and the whole problem disappears. ## How to check it without rereading the whole document 1. **Check the total against the sum of the rows** — Catches the missing row and the duplicated one. 2. **Pick two rows at random and compare the whole row** — Not the number: the entire row, to see whether it is aligned. 3. **Look at the page break** — That is where a row splits, and where nobody looks. 4. **And correct in the platform, not on the document** — That way there is a record of what changed and who changed it. > [!NOTE] > If a document with tables reads badly time after time, it is usually the document rather than the reading: same supplier, same template, same failure. Raising it with whoever issues it fixes all the following ones at once. **Should I extract every line?** Only if you will use them. If the total is enough, asking for less fails less. **What about a spreadsheet?** Far better: there the rows are real rows, not a picture of rows. **Does uploading at higher resolution help?** It helps read the digits, not place the rows. Different problems. ## Ejemplos **A company extracts a supplier's delivery note lines and the totals add up.** - Cross-checks two whole rows at random and the page break → A quantity turns up on the neighbouring reference, which the total was never going to reveal. **A table reads with its columns crossed.** - Reviews the extraction against the image → The figure ends up in its column. **The table splits across two pages.** - Checks it was read in full → No row is missing. **Only the total is extracted and the detail was needed.** - Defines which rows or columns matter → The extraction serves what is needed. **A skewed scanned table reads badly.** - Straightens it before uploading → Reading improves with no further tweaks. **Long tables are keyed by hand.** - Lets them be read and reviews the uncertain → Time goes on checking. --- --- id: KB-DI-019 url: https://app.codecontract.io/help/documents-and-ai/documents-that-bring-more-personal-data-than-needed idioma: en categoria: documentos-ia subcategoria: subir audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-010, KB-GL-013, KB-DI-014] citadoPor: [KB-DI-008] --- # Documents that bring more personal data than needed _You ask for one thing and it arrives inside a document carrying five more details you never needed._ **Responde a:** they sent a document with excess personal data · can I ask for details to be redacted · do I need to keep the full ID number · hiding data before sharing a document You ask for proof of good standing and a full employment history arrives. You ask for a technician's qualification and their entire file turns up. Nobody is acting in bad faith: whoever sends it grabs what they have. The problem is that from that moment you hold it. ## What to do in each case | What arrived | What to do | Why | | --- | --- | --- | | The right document with excess data | Ask for the narrower document if one exists | What you do not hold needs no safeguarding | | A document you did not ask for | Do not file it, and say so | Keeping it «just in case» makes you responsible for it | | Third parties' data inside (relatives, patients, other clients) | Return it and ask for a version without | There you do not even hold the permission | | Exactly what was needed | File it and move on | That is the aim | > [!IMPORTANT] > Before sharing a document with excess data outwards, there is a technical detail that surprises many people: **covering something with a black box in a PDF does not always delete it**. If the text is still underneath, anyone can copy it or see it in another program, and the document looks properly redacted. Hidden on screen is not the same as removed: if the document is leaving your organisation, make sure the data is gone, not merely invisible. ## How to ask so it does not happen 1. **Say what you need to prove, not which document you want** — «That they are in good standing» allows several papers, some leaner. 2. **Accept the narrowest one that works** — If a certificate suffices, do not ask for the full report. 3. **And if excess data arrives, say so at once** — Three weeks later nobody returns anything. > [!WARNING] > The reasoning to disarm is «since we have it, let us keep it»: **every stored item is one to safeguard, to justify if someone asks, and to delete some day**. A surplus document gives you nothing and adds obligations — and if there is ever an incident, its scope is measured by what you held, not by what you used. ## And if you already hold it **En corto** - Replace it with the narrower version once the issuer can send one. - Withdraw what you should never have received, recording that it was withdrawn. - And review who had access while it was there. > [!NOTE] > Which data you may request, how long to keep it and what to do when third parties' data arrives depend on the data protection framework that applies to you — the **GDPR** in Europe — and on your activity. **Your adviser settles that**; here it is the practical reflex: ask for exactly what is needed and do not keep the surplus. **Can I redact the document they sent me?** You can keep a narrowed version, but stay clear about which is the original. **What if the supplier has no other version?** Keep what there is, with restricted access, and note why it was needed. **Does this apply to what we send out?** Equally, and there you are the one sending someone else's surplus data. ## Ejemplos **A company receives a technician's full file when all it asked for was one qualification.** - Returns it, requests the specific certificate and records that the other was not filed → It keeps what it needed and none of the duty to safeguard the rest. **A document arrives with more personal data than was requested.** - Checks what it contains before filing it → You know what you are holding. **The whole document is requested when part would do.** - Requests only what needs checking → You hold less of what was never needed. **The whole team can open that document.** - Limits who sees anything containing personal data → Access stops being general. **It is shared with a client without reviewing the contents.** - Reviews the content before sharing → Third-party data is not forwarded unintentionally. **It is kept indefinitely just in case.** - Applies the retention period → What is kept has a reason and a period. --- --- id: KB-DI-020 url: https://app.codecontract.io/help/documents-and-ai/documents-that-carry-no-date idioma: en categoria: documentos-ia subcategoria: lectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-016, KB-DI-009, KB-DI-021] citadoPor: [KB-DI-015] --- # Documents that carry no date _They arrive with no date, or with three different ones. What gets recorded there drives every expiry that follows._ **Responde a:** the document has no date · what date to record if the certificate has none · issue date or received date · the document has several dates A certificate with no date, a signed sheet with the date in small print, a document carrying three different dates on one page. It is more common than it sounds, and the decision made at that moment does not stay there: it drags along every alert that depends on it. ## The dates you may find, and which is which | Date | What it means | When it is the right one | | --- | --- | --- | | Issue | When the signatory produced it | Nearly always: it is what the period counts from | | Validity or expiry | How long it holds good | If present, it overrides the rest | | Signature | When someone signed it | It can be later than issue | | Received | When it reached you | It never replaces the others | > [!IMPORTANT] > The last row is the shortcut that wrecks the arithmetic: **recording the date you received it as if it were the document's shifts every expiry forward**. A certificate issued in January arriving in April will warn you three months late for the rest of its life — with nothing to give it away, because the record is consistent with itself. If the document carries no date, the answer is not today's date: it is to ask. ## What to do when it is missing 1. **Read the whole document before deciding** — It is usually in the footer, the stamp or beside the signature. 2. **If it genuinely is not there, ask the issuer** — An email from them stating the date works, and it gets filed. 3. **And if it cannot be obtained, record that** — «No date on the document» is information; an invented date is not. 4. **With a cautious expiry meanwhile** — Short: better to review too often than to trust a date that does not exist. > [!WARNING] > Watch out for documents carrying two dates months apart: **issue and signature do not always match, and sometimes the gap is deliberate**. A report dated March and signed in June may be perfectly correct — drafted then, validated later — or may show someone signed late. Either way, keep both and know which one you count the period from, because whoever reviews it will ask about exactly that gap. ## When what is missing is the expiry **En corto** - Many documents do not expire themselves: what they certify does. - If the period comes from your policy, record it as yours, not as the document's. - And if the issuer has its own frequency, that overrides whatever you decide. > [!NOTE] > How long a document without an explicit expiry stays valid depends on the document type and on whoever requires it from you. **Your adviser or the client settles that**; here it is about not inventing a date nobody can later trace. **Can I use the date of the email it came with?** As a reference yes, recorded as such. As the document's date, no. **What if the date is in another format or language?** Check it the first time: that is where day and month get swapped most. **Is it worth rejecting a document with no date?** If the deadline matters, yes: asking properly is cheaper than dragging it. ## Ejemplos **A company records the received date as the date of a certificate issued three months earlier.** - Asks the issuer for the real date and records it, noting that it was missing → The renewal alert lands when it should instead of three months late forever. **The document carries no date and the warning does not work.** - Records the known date when filing it → The warning works again. **The upload date is assumed to be the document's date.** - Distinguishes the two and notes which is which → The history is true. **Nobody knows from when an undated document is valid.** - Asks the issuer to include it → The problem is solved at source. **The date is estimated and nobody knows it is an estimate.** - Flags the figure as estimated → The estimated is told from the certain. **A client asks about validity and there is no figure.** - Checks what was recorded and explains it → The answer is honest and useful. --- --- id: KB-DI-021 url: https://app.codecontract.io/help/documents-and-ai/theyre-asking-for-a-translation idioma: en categoria: documentos-ia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-013, KB-NO-022] citadoPor: [KB-DI-020] --- # They're asking for a translation _Ask first what kind of translation they need: the gap between the two is measured in days and money._ **Responde a:** asked to translate a certificate · sworn translation of a document · will an ordinary translation do · document in another language for a client **Before commissioning anything, ask whether an ordinary translation will do or they need a sworn one.** They are two different products with very different timescales and prices, and requesters often have not specified which because they did not know there were two. ## The difference, briefly | Type | What it usually suffices for | | --- | --- | | Ordinary translation | Someone understanding what the document says | | **Sworn translation** | **Standing up before an authority or a formal third party** | | Just a summary or a few fields | Many internal cases are settled this way | > [!IMPORTANT] > **The original is never replaced by the translation: it is accompanied by it.** The translation explains, the original proves. Sending only the translated version is a common mistake that forces a resend, because the recipient can check nothing against it — and if what is ever disputed is a date or a figure, what gets examined is the source document. ## What to ask before commissioning 1. **What do you need it for?** — If it is to understand it, a sworn translation is rarely needed. 2. **Is a third party asking, or is it for your files?** — That decides whether formal requirements apply. 3. **Would translating part of it do?** — With long documents often yes, and it changes the timescale entirely. > [!WARNING] > On machine translation, which is the first thing everyone tries: **it is for understanding, not for delivering**. A machine translation of a certificate reads well and fails exactly where it matters most —proper names, units, dates and sector-specific terms— and those errors are invisible unless you know the language. As a support to grasp what it says, perfect; as a document you hand to a client or an authority, no. > [!NOTE] > When a sworn translation is required, who may issue one and what additional requirements may apply depends on the country and the body requesting it. **Whoever is asking, or your adviser, settles that**; here we explain what to ask so you do not commission the expensive one when the other would do, or the reverse. **Will a machine translation do?** To understand the document yes; to hand it over, no. **Do I send only the translation?** No: always alongside the original. **Do I have to translate the whole document?** Ask. Often the relevant part is enough. ## Ejemplos **A sworn translation is commissioned for a long document that only needed understanding.** - Asks beforehand what it is needed for and whether part of it would do → It is settled in a day with an ordinary two-page translation. **Only the translated version of a certificate is sent to the client.** - Attaches the original alongside the translation → The client can check dates and names, and no resend is needed. **A translated document is requested and the whole thing is translated.** - Asks which part they need to understand → Only what is needed gets translated. **Nobody knows whether an official translation is required.** - Asks before commissioning one → The right thing is commissioned. **It is translated and the original is lost.** - Keeps the original with the translation → Both versions exist. **The translation is requested with the deadline looming.** - Asks about the requirement when the matter starts → The timeline includes translation time. --- --- id: KB-DI-001 url: https://app.codecontract.io/help/documents-and-ai/how-the-ai-reads-your-documents idioma: en categoria: documentos-ia audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-PR-002, KB-DI-002] citadoPor: [KB-DI-003, KB-DI-002, KB-CD-001, KB-MA-001] enLaApp: https://app.codecontract.io/documents --- # How the AI reads your documents, and when to trust it _What it extracts, what the confidence level means and who has the final word._ **Responde a:** how does the AI read documents · what is the confidence level of an extracted field · the AI misread a field what do I do · automatic data extraction from invoices · OCR for scanned documents When a document arrives in a case it does not just sit there as a file: it is read, and the fields you asked for are extracted. Invoice number, amount, due date, company name. That is what later lets you search for "every invoice over €5,000" instead of opening fifty PDFs. **En corto** - The AI proposes the data; you confirm. It never closes a field on its own. - Each field carries a confidence level telling you where to look. - If you correct a field, the record shows that you corrected it and when. - A blurry or skewed document lowers confidence; that is a warning, not a failure. **The journey of a field** — Confidence does not decide for you: it tells you how hard to look. Confirmation is always human. ## What the confidence level means It is not a quality score for the document: it is how sure the system is that it read that specific field correctly. The same document can have the amount at high confidence and the date at low, because the date was handwritten in a margin. | Confidence | What it usually means | What to do | | --- | --- | --- | | High | Printed field, sharp, where it was expected | A glance is enough | | Medium | It was read, but the format or position was unusual | Check it before confirming | | Low | Shaky photo, rotated document, handwritten or struck-through field | Review it fully; sometimes it is worth asking for a better copy | > [!WARNING] > Low confidence does not mean the value is wrong: it means the system is not committing. Confirming it without looking is exactly the use it should not get. ## What to do when it reads something wrong 1. **Correct the field by hand** — It is immediate, and the record shows the final value came from you. 2. **See whether the document can be improved** — A photo with shadow or backlight reads badly. Asking for a retake costs less than correcting twelve fields. 3. **If it repeats with the same document type, say so** — A one-off failure on a bad photo is not the same as a pattern with a specific form, and the second can be tuned. ## What it does NOT do - It does not decide whether a document is valid: you or your process do. - It does not reject documents based on their content. - It does not modify the original file, which is kept exactly as it arrived. - It does not read in SmartCheck: there, documents are sealed as-is, uninterpreted. ## Frequently asked questions **How long does reading a document take?** Seconds. If it takes much longer it is not thinking: something has failed and it is worth reloading. **Does reading a document consume credits?** Yes, automatic reading is one of the actions that consumes credits. Correcting a field by hand does not. **Can I ask for fields that are not in the document?** You can ask for them as data for the person to fill in. If they are not on the page, reading does not invent them: it leaves them empty. **Does it read documents in other languages?** Yes. What affects reading most is image quality, not language. **What if the document has several pages or several invoices?** All of them are read. When one document contains several occurrences of the same group of fields, each is extracted separately. ## Ejemplos **An accountancy receives 300 invoices a month and needs the number, date and net amount from each.** - Defines those three fields on the process request - Reviews only the ones flagged medium or low confidence - Confirms the rest in bulk → About 30 get reviewed by hand instead of 300, and the ones reviewed are exactly the ones that needed it. **Everything read is approved without looking.** - Reviews whatever the AI flags as uncertain → The work shifts from keying to checking. **A high-confidence figure turns out to be wrong.** - Corrects the figure and records it → The indicator guides and the last word stays human. **One document type always reads badly.** - Checks whether the format matches what is expected → The problem is tackled at source. **A hundred invoices a month are keyed by hand.** - Lets them be read and reviews the uncertain ones → Time goes on checking rather than copying. **The reading is distrusted and everything is checked.** - Filters by confidence and starts at the bottom → Review concentrates where the risk is. --- --- id: KB-DI-002 url: https://app.codecontract.io/help/documents-and-ai/uploading-documents-and-taking-photos idioma: en categoria: documentos-ia audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-001, KB-PR-002, KB-TL-003] citadoPor: [KB-DI-004, KB-DI-012, KB-CR-005, KB-DI-001] enLaApp: https://app.codecontract.io/documents/upload --- # Uploading documents and taking photos that read well _Formats, size limit and the four mistakes that make a photo unreadable._ **Responde a:** how do I upload a document · photograph a document with my phone · the file is too large to upload · which formats can I upload · the document comes out skewed when photographed A good share of the documents entering the platform are not PDFs: they are phone photos taken by someone on a building site, in a warehouse, or outside a notary's office. Whether that photo can be read comes down to four things, and all four are fixed at the moment it is taken. **En corto** - The limit is 30 MB per file, the same everywhere on the platform. - Any format works for certifying; signing needs a PDF. - From a phone, use the photograph option inside the link rather than attaching from the gallery. - A 200 dpi scan reads just as well as 600 and weighs a fraction. ## The four things that ruin a photo | Problem | What happens when read | How to fix it | | --- | --- | --- | | Shadow or backlight | Half the page goes dark and cannot be read | Stand with your back to the window, not facing it | | Skewed document | Confidence drops on almost every field | The platform straightens it, but better to shoot it square | | Blurry photo | Text comes out doubled and is not recognised | Rest the document on a table rather than holding it up | | Cropped | Exactly the field you needed is missing | Frame the whole document with a little margin | > [!NOTE] > If the document has several pages, one photo per page beats one photo of two pages at once. A shot of a double spread reads badly almost every time. ## When the file is too large Almost everything over 30 MB is a scan at unnecessarily high resolution. Rescanning at 200 dpi solves it without losing anything useful: it is more than enough for text, and the file drops to a fraction of the size. If it is a hundred pages, splitting it by section also makes things easier to find later. ## Frequently asked questions **Which formats are accepted?** For certifying, any: PDF, photo, spreadsheet, video, audio. Signing needs a PDF, and anything else is converted. **Can I upload several documents at once?** Yes. What is worth avoiding is putting different documents into one file: kept separate they are easier to find and to read. **Is my original file modified?** No. The original is kept exactly as it arrived. Anything generated — a reading, a signed PDF — sits alongside it. **Can an external participant photograph from their phone?** Yes, from the link itself, with nothing to install. It is the most common route and the one that works best. ## Ejemplos **A site foreman photographs twelve delivery notes at the end of the day and half come out unreadable.** - Rests them on the bonnet instead of holding them one-handed - Stands with his back to the sun - Takes one photo per note instead of two notes per photo → All twelve read first time and nobody has to go back to site to retake anything. **The photo comes out blurred and cannot be read.** - Retakes it with the document flat and good light → Reading improves without changing anything in the system. **The photo is taken with a shadow across the text.** - Changes position before shooting → The text comes out legible first time. **A skewed scan is uploaded.** - Rotates it before uploading → Automatic reading works. **Several pages are photographed in one image.** - Captures one page per image → Each page is read separately. **The document has staples or folds covering text.** - Flattens it before capturing → No text is missing from the reading. --- --- id: KB-CC-003 url: https://app.codecontract.io/help/contacts-and-channels/keeping-contacts-up-to-date idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-001, KB-CC-002, KB-CC-018] citadoPor: [KB-CC-008, KB-ET-012, KB-CC-010, KB-CC-005, KB-CC-006, KB-CR-010] --- # Keeping contacts up to date _A wrong contact costs two weeks, and it was almost always knowable in advance._ **Responde a:** the supplier's email is wrong · update contact details · duplicate contacts · the person no longer works there Most stalled cases are not stalled because the other side does not want to: they are stalled because the notice went to an address nobody reads any more. And the system knew that from day one. **En corto** - A bounce is information: the address is wrong, not that they are ignoring you. - Duplicating a contact splits their history in two and neither half tells the whole story. - Asking for a mobile number at onboarding saves weeks later. ## The three things that most clutter it | Problem | How you notice | Fix | | --- | --- | --- | | Bouncing addresses | The case flags it on the first send | Fix it on the contact record, not just that send | | Duplicate contacts | The same person with two records | Merge them so the history is not split | | People who have left | They never open anything | Ask the company for their replacement | ## The review worth doing Once a quarter, look at contacts that have bounced or have opened nothing for months. There will be half a dozen, they take twenty minutes to fix, and they are exactly the ones about to block your next case. > [!WARNING] > Fixing the email only on one send leaves the record wrong, and the next case fails the same way. Fix the record. > [!NOTE] > When a third party tells you their contact person has changed, update it that day. It is the only moment you have the right detail without hunting for it. **Can a company have more than one contact?** Yes, and it helps: one for paperwork, another for invoicing. **What happens to history when merging?** It joins up. That is the reason to merge rather than delete one. **Can I import contacts from our system?** Yes, and it is the fastest way to start. ## Ejemplos **A company has eleven stalled cases and none are moving.** - Filters contacts that bounced - Fixes seven addresses on their records - Asks for replacements for two people who have left → Nine of the eleven cases move that week. **An email bounces and nobody corrects it.** - Updates the contact on the first bounce → Notices stop getting lost. **Each person has their own version of the contact.** - Centralises the company record → The supplier receives a coherent message. **The contact has not been updated in two years.** - Reviews contacts at every campaign → The address book reflects reality. **You discover the contact left when chasing.** - Asks for the new contact before the next round → The chase reaches somebody who can act. **There are duplicate contacts at the same company.** - Merges the duplicates → The supplier receives one, not three. --- --- id: KB-CC-008 url: https://app.codecontract.io/help/contacts-and-channels/a-contact-who-is-both-client-and-supplier idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-006, KB-CC-003] citadoPor: [KB-CC-015] --- # When the same contact is both client and supplier _One record or two, and what breaks if you choose wrong._ **Responde a:** the same company is both client and supplier · duplicate a contact per role · one contact in two different processes · organising contacts with multiple relationships It happens more than you would think: the company you buy from also buys from you, or the firm that runs your payroll is also a client. The question is whether that is one record or two, and the answer matters because it affects the history. ## The rule **One record per real person or organisation, not per relationship.** A company is one company even if you have two dealings with it. Duplicating splits its history into halves and neither tells the whole story. | Situation | What to do | | --- | --- | | Same company, same contact person | One record | | Same company, different people per area | One record per person, all under the same company | | Two entities in the same group | Two records: they are different entities and invoice separately | ## What separates the two relationships is not the record It is the case. Onboarding them as a supplier and contracting them as a client are two separate cases about the same contact, each running its own course. The record only says how to reach that person. > [!WARNING] > If you duplicate by role, sooner or later you will update the email on one record and not the other. From then on half your notices go to an address nobody reads, and it takes weeks to work out why. > [!IMPORTANT] > Be careful what each side sees when a company is both. Being your supplier does not give them access to what you hold on them as a client: they are separate cases and it is worth checking permissions reflect that. > [!NOTE] > If you already have duplicates, merge rather than delete one. Merging joins the history; deleting loses half of it. **Can I tag the relationship?** Yes, and that is what lets you filter "my suppliers" without duplicating anything. **Does the contact see both cases?** Only what you asked them for in each, through their own link. **What if their contact person changes?** Update the record, and both cases use it. ## Ejemplos **A company has its accountancy firm twice: as a supplier and as a client.** - Merges the two records - Keeps the two cases separate → Stops sending notices to an old address that had only been corrected on one of them. **The same company is client and supplier and everything mixes.** - Separates files by relationship type → Each relationship has its own history. **A supplier notice reaches whoever handles the client side.** - Records the contact for each relationship → The notice reaches the right person. **Information from one relationship is shared in the other.** - Checks the file before sharing → Nothing crosses that should not. **The company record gets duplicated.** - Keeps one company with two relationships → Shared data is updated once. **A report adds both relationships together.** - Queries by relationship type → Each figure says what it is. --- --- id: KB-CC-010 url: https://app.codecontract.io/help/contacts-and-channels/when-the-contact-person-changes idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-003, KB-CC-004] citadoPor: [KB-CC-014, KB-CC-017] --- # When the contact person changes _The silent cause of half the cases that stall._ **Responde a:** the contact person no longer works there · change of contact at a supplier · notices going to someone who left · updating a company's contact It is the cause nobody suspects and it explains a huge share of dead cases: the person you write to left that company months ago. Their email may still be active, may bounce, or may be read by someone with no idea what it is about. ## How to recognise it | Sign | What it usually means | | --- | --- | | It suddenly bounces after months working | They left and the account was closed | | It is delivered but never opened | Their mailbox is alive and nobody reads it | | Someone else replies asking what it is about | Somebody inherited the mailbox without context | | They reply from a different address | They have already changed and did not tell you | > [!IMPORTANT] > The second row is the worst because it produces no error. The system says delivered, you assume it arrived, and the case waits for someone who no longer exists at that company. ## What to do when it happens 1. **Fix it on the record, not just on that send** — Fix it only there and the next case fails identically. 2. **Ask who replaced them rather than sending blind** — A one-minute call to their switchboard resolves months of silence. 3. **Keep both contacts if they coexist** — Many companies have one for paperwork and another for invoicing. ## How to catch it earlier **En corto** - Reviewing quarterly who has opened nothing in months. - Asking for a mobile at onboarding: it survives job changes better than email. - And updating the day a third party tells you it is changing, not when you need it. > [!WARNING] > When someone tells you they are leaving and gives you their replacement's details, update it that same day. It is the only moment you hold the right detail without hunting, and it vanishes the moment that mailbox closes. > [!NOTE] > If a contact has opened nothing in a year, it is not a contact: it is an address. Treat it as such before launching an important request at it. **Can I have several contacts per company?** Yes, and you should: it halves this problem. **Is history lost when the person changes?** No. History belongs to the company and the case. **What if nobody at that company replies?** The main phone number. It is slow, and still faster than three months of silence. ## Ejemplos **A company has had no reply from a supplier in four months and assumes they are uncooperative.** - Checks the log: delivered but never opened - Phones the switchboard and gets the replacement → The supplier delivers in two days; the person they were writing to had left in the spring. **The contact changes and notices keep going to their address.** - Updates the contact on the files → The notice reaches somebody who exists. **The new contact does not know what had been delivered.** - Shows them the file's status → They catch up without phoning anyone. **A new file is opened for the new person.** - Continues the existing one, changing the contact → No history is lost. **Nobody knows who replaces the previous contact.** - Asks the company before chasing → The request reaches somebody who can act. **The old contact keeps receiving information.** - Revokes their access on updating → Information stops going to somebody it should not. --- --- id: KB-CC-011 url: https://app.codecontract.io/help/contacts-and-channels/when-an-email-does-not-arrive idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-001, KB-CC-002] citadoPor: [KB-IN-014, KB-CC-018] --- # When an email does not arrive _"I never got anything" is nearly always one of four things, and only one is the email's fault._ **Responde a:** client says the email never arrived · emails going to spam · not receiving the signing link · email deliverability problems It is the commonest incident and the worst diagnosed, because the phrase it arrives with — "I never got anything" — covers four different situations that are fixed in different ways. ## The four causes, by frequency | Cause | How to recognise it | What to do | | --- | --- | --- | | Address typed wrong | The send shows as bounced | Fix the contact and resend | | It is in the junk folder | Shows delivered and unopened | Ask them to look there; then another channel | | Someone else opened it | Shows opened and the person never saw it | Send to the right person, not the generic mailbox | | Their company filter blocked it | Shows neither delivered nor bounced | Another channel, and tell their IT | > [!IMPORTANT] > All four are told apart by looking at the send status, and none is told apart by resending. Resending without looking is what turns a two-minute incident into three days of crossed emails. ## What prevents most of them 1. **Send to people, not generic mailboxes** — "info@" and "admin@" are where the notices that matter go to die. 2. **Verify the address when creating the contact** — One extra letter surfaces weeks later, with the deadline on top. 3. **For anything urgent, a channel with more reach** — A phone message does not compete with a corporate email filter. 4. **And let it chase by itself** — A reminder after three days resolves half the "never arrived" cases with nobody calling. > [!WARNING] > Watch the third case. When mail goes to a shared mailbox, someone opens it, decides it is not for them, and there it dies: it shows delivered and opened, and the person who had to sign never saw it. It wastes the most time because the data says everything went fine. ## If it keeps happening with the same client Then it is not an incident, it is their filter. What works is talking to their IT so they recognise the sender; what does not work is retrying and expecting a different outcome. **En corto** - Check the status before resending. - A named person beats a generic mailbox. - And if email fails twice, change channel instead of insisting. > [!NOTE] > Every resend consumes the same as the first send, because it is a new action. One well-addressed send with automatic reminders costs less than five manual ones to the wrong address. **Can I tell if they opened it?** You can see whether it shows opened; in some mail clients that signal is approximate. **Can I send by two channels at once?** You can, and for urgent items it pays. It counts as two actions. **Does a custom domain stop it going to spam?** It helps considerably, especially when the recipient already knows you by that domain. ## Ejemplos **A supplier says the signing link never arrives, after four resends.** - Checks the status: delivered and opened in a generic mailbox - Resends to the named person → They sign that afternoon, after three weeks of emails that were arriving all along. **An email bounces and nobody sees it.** - Checks bounces after each send → The fault is fixed before chasing. **The recipient's domain blocks the sender.** - Agrees with their IT to allow it → The block is resolved for the whole company. **The email lands in junk.** - Asks them to add the sender to their safe list → The next notice reaches the inbox. **People keep emailing when email is the problem.** - Changes channel after the second attempt → The notice arrives where it gets read. **The address is mistyped on the record.** - Corrects the contact and resends → The send arrives first time. --- --- id: KB-CC-012 url: https://app.codecontract.io/help/contacts-and-channels/writing-to-someone-who-does-not-know-you idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-004, KB-TL-003, KB-CC-020] citadoPor: [KB-CL-012, KB-CC-014, KB-CL-016] --- # Writing to someone who does not know you _The first message to a third party decides whether they reply or take it for a scam._ **Responde a:** first message to a new supplier · recipient thinks it is phishing · how to request documents from an outsider · getting people to trust a link we send When you ask something of someone who has never heard of you — a supplier's accountant, a client's engineer, a private individual — the message competes with a reasonable instinct: that an email with a link asking for documents looks exactly like a scam. ## What makes them reply | Element | Why | Where to put it | | --- | --- | --- | | Who you are, with a recognisable name | "Code Contract" means nothing to them; your company does | In the subject and first line | | Why you are writing | The contract, the order, the specific site | Second line, with the reference | | Exactly what you need | A short list, not "the documentation" | Visible without opening anything | | And by when | Without a date there is no urgency | At the end, with the reason | > [!IMPORTANT] > The first element decides. A message arriving on behalf of an unknown platform gets deleted; the same message on behalf of the company they work with gets opened. Putting your brand on what they receive is not cosmetics: it is response rate. ## What makes them NOT reply **En corto** - A generic subject like "Outstanding documentation". - A link with no explanation of where it leads. - Asking for "the usual" without saying what that is. - And sending it to a generic mailbox hoping someone distributes it. > [!WARNING] > If you also ask them to register, create a password or install something, half will not. Supplying documents needs no account: they enter by their link, upload theirs, done. If your message suggests otherwise, you are complicating it for nothing. ## When they still do not reply 1. **Check the status before insisting** — Bounced, unopened, or opened by someone else are three different problems. 2. **Change channel before changing tone** — A text saying "I've emailed you" unblocks many situations. 3. **Call once, and note what they say** — A thirty-second call resolves what five emails do not. 4. **And if the problem is not knowing what to send, show them** — One example of what you want beats a description. > [!NOTE] > Whoever receives the request pays nothing to supply or sign: no account, no licence, no balance needed. All consumption is on your side, and it is worth saying so when someone asks whether it will cost them. **Can it be sent from our domain?** Yes, and it considerably improves trust and deliverability. **What if they say it looks like phishing?** Good sign: those are alert people. Confirm by another route and carry on. **Are reminders worth sending?** Yes, spaced out. Most people reply to the second, not the first. ## Ejemplos **A company sends document requests and only a third reply.** - Puts its brand and the order reference in the message - Adds the concrete list and a date → First-send response rate rises and chasing stops being the main job. **You write to somebody who does not know you and they do not reply.** - Explains who you are and why you are writing → The email is opened rather than dismissed. **The email looks automated and lands in junk.** - Personalises the subject and sender → The notice reaches the main inbox. **The recipient doubts whether the link is legitimate.** - Gives notice beforehand by another route → The link is opened with confidence. **Too much is asked for at first contact.** - Asks for little and explains the rest later → The first attempt completes. **Nothing says what happens after replying.** - Explains the next step in the notice itself → The recipient knows where they stand. --- --- id: KB-CC-013 url: https://app.codecontract.io/help/contacts-and-channels/writing-to-a-public-authority idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-012, KB-CC-002] citadoPor: [KB-LE-015] --- # Writing to a public authority _What differs from writing to a company, and what to keep either way._ **Responde a:** communicating with a public authority · electronic registry receipt · submitting documents to an authority · keeping an official acknowledgement Writing to a public body differs fundamentally from writing to a company: there is usually a mandatory formal channel, and using another does not count. The email you sent the case officer may have served to talk, but not to submit. ## The two channels, and what each is for | Channel | What it is for | What remains | | --- | --- | --- | | Formal (registry, portal, platform) | Submitting, responding, meeting a deadline | A receipt with date and number | | Informal (email, phone) | Clarifying, asking, speeding things up | Whatever you keep | > [!IMPORTANT] > The formal receipt is the important document, more than what was submitted. It is the only thing proving it arrived and when, and it is exactly what belongs in the file next to what you sent. ## What to keep from each procedure 1. **What was submitted, exactly as submitted** — Not the working draft: the exact file that went. 2. **The receipt, with its number and date** — It is what will be asked for if the deadline is disputed. 3. **Their reply, in the same file** — Including requests for further information, which usually run short. 4. **And relevant informal conversations** — A line with the date and what was said; not formal evidence, but it orients. > [!WARNING] > The costliest failure is a notification landing in a mailbox nobody watches. Deadlines run regardless, and many are ten days. Notifications should reach somewhere with an owner, not a generic address created years ago. ## When several procedures run at once **En corto** - One file per procedure, not a folder with everything from that body. - With the deadline visible, which is almost always what matters. - And who answers for it, even when an adviser handles it. That last point prevents silence: when a third party handles a procedure, both sides easily assume the other is responding. > [!NOTE] > If your advisers file on your behalf, ask for the receipt and keep it yourselves. It is not distrust: the deadline is yours, and so is the consequence of not being able to prove it. **Is email valid for submitting?** Unless the body expressly accepts it, no. **What if their system fails?** Keep dated evidence of the attempt; it is usually provided for. **Should submissions be sealed?** The receipt gives the date; sealing the sent file adds proof of content. ## Ejemplos **A company receives an official request in a generic mailbox and finds out late.** - Routes notifications to a file with an owner - Keeps the receipt and reply for each procedure → Deadlines stop depending on someone checking a mailbox that belongs to nobody. **A public body is written to through a channel they do not monitor.** - Checks the official channel before writing → The submission reaches where it is processed. **There is no record of having filed something.** - Keeps the filing receipt → The filing is demonstrable. **Filing happens out of time through miscalculation.** - Records the deadline with its own warning → The margin does not depend on remembering. **A document is missing and it is discovered on filing.** - Checks what is missing in advance → The gap closes with time to spare. **A reply arrives and nobody attaches it to the file.** - Files the reply with what was submitted → The file explains itself. --- --- id: KB-CC-014 url: https://app.codecontract.io/help/contacts-and-channels/reaching-the-right-person idioma: en categoria: contactos-canales audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-010, KB-CC-012, KB-CC-009] citadoPor: [KB-CC-015, KB-CC-019, KB-ET-020, KB-CC-020] --- # Reaching the right person _The document does not arrive because you are asking someone who does not have it. How to find who does._ **Responde a:** i do not know who to ask for the documents · who handles this at the supplier · generic mailbox does not reply · finding the right contact When a request stalls, the cause looks like a lack of interest and is nearly always something else: you are asking someone who does not have that document and does not know who does. It is especially common with mid-sized companies, where the salesperson who sold to you never touches documentation. ## Who usually holds what | Document | Who normally holds it | Who NOT to ask | | --- | --- | --- | | Insurance and policies | Administration or their broker | The salesperson | | Quality certifications | Quality or technical management | Administration | | Employment documentation | HR or their payroll adviser | The site manager | | Product datasheets | Technical or production | The salesperson, who sends the old one | > [!IMPORTANT] > The fourth row explains a problem that looks like bad faith and is not: the salesperson sends an outdated datasheet because it is the one in their folder. They are not deceiving you; they simply do not maintain that document. ## How to find out without going round in circles 1. **Ask directly who handles it** — "Who handles quality documentation at your company?" saves three weeks. 2. **Ask for that person's email rather than a forward** — A forward loses the link and the context, and nobody knows who answers. 3. **Save the right contact in their record** — With their role: it stops you repeating the search a year later. 4. **And note who it was NOT** — That is useful information too, especially in large companies. > [!WARNING] > Avoid generic mailboxes for anything with a deadline. An "info@" or "admin@" works for a sales enquiry and is where dated requests die: someone opens it, decides it is not for them, and that is the end. ## When the right person changes **En corto** - It is the number one cause of requests that stop being answered from one month to the next. - It is spotted quickly: what used to be answered in two days stops for no reason. - And it is fixed by asking, not by insisting. Insisting to an address that no longer exists, or to someone who has left, generates reminders nobody reads and the impression that the supplier "is not cooperating". > [!NOTE] > When what you need is held by a third party of your supplier — their accountant, their insurance broker — it can be requested from that third party with the supplier's agreement. It is usually much faster and avoids the forwarding step. **Can I keep several contacts per company?** Yes, and it helps: one commercial, one for documents, one technical. **What if I only get the generic mailbox?** Write there asking for the person's contact; that is the first request. **How do I know they are still the right person?** If they stop replying suddenly, they usually are not. ## Ejemplos **A company has spent five weeks asking a supplier's salesperson for a certificate.** - Asks who handles quality and requests the direct contact → Receives the certificate the next day and saves the right contact for next year. **A generic mailbox is written to and nobody replies.** - Asks for the name of whoever handles it → The request reaches a specific person. **The contact on record is not the decision-maker.** - Asks who can resolve it → You write to somebody who can act. **Three people are written to and nobody takes it on.** - Addresses the request to one and copies the rest → There is a clear owner. **The right person is in another department.** - Asks for a redirect and records the new contact → The next request already goes right. **Nobody knows who handles that topic at the company.** - Asks the usual contact → You reach the person in one hop. --- --- id: KB-CC-015 url: https://app.codecontract.io/help/contacts-and-channels/asking-several-people-for-the-same-thing idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-014, KB-CF-012, KB-CC-005, KB-CC-008] citadoPor: [KB-CC-018] --- # Asking several people for the same thing _Sending it to three just in case feels safer and usually means none of them replies._ **Responde a:** send the request to several people at the company · copying in several contacts · nobody replies although i sent it to three · who to address a document request to When something is urgent, the reflex is to send it to every contact you have at that company. It is understandable and counterproductive: when a request reaches three people without saying whose it is, each assumes another will answer. It is called diffusion of responsibility and it works the same everywhere. ## What happens depending on who you send it to | How it is sent | What usually happens | | --- | --- | | To one named person | They reply or say who should | | To three, without saying whose it is | None replies, and all three think it is covered | | To a generic mailbox | Someone opens it, decides it is not theirs, and it dies | | To one person, with another copied | It works: there is an owner and a witness | > [!IMPORTANT] > The fourth row is barely used and solves the real case. If you want more than one person aware, make one the recipient and copy the other: the request still has an owner, and the second person knows it exists without feeling responsible for replying. ## When sending to several is right **En corto** - When each must supply something different: then it is not one request, it is several. - When the deadline is very short and you prefer redundancy to order. - And when you do not know who handles it: there the first request is "who handles this?", not the document. The first case is the commonest in practice and is better solved by splitting: one request per person, each with their own. That way you can see who is missing, without the ambiguity of a shared list. > [!WARNING] > On cost, so it does not weigh on the decision: **a request counts as one action even when it goes to several contacts**, and a bulk send counts as one, not one per recipient. Verified in the platform's own action catalogue. So the reason not to send it to three is not spend: it is that it works worse. ## When two contacts really are needed 1. **Name the one who answers** — In the text itself: "Marta, can you send it over?". It costs five words. 2. **Make clear what the other is there for** — "Copying you so you know" stops both from waiting. 3. **And if the owner changes, change it here too** — Chasing someone who no longer handles it is the commonest cause of never-ending requests. > [!NOTE] > When the answer arrives, it lands in the file whoever sends it. That a different person supplies it does not break anything — what helps is that it stayed clear who was on the hook. **What if the right person is on leave?** Send to their cover by name, not to the whole team. **Can I see which of the three opened it?** Yes, the send status shows it, and it usually explains the silence. **Should I copy their manager?** As a last resort it works; as a habit, it burns the resource. ## Ejemplos **A company sends the same request to three contacts at a supplier and nobody replies.** - Resends to one named person, copying the other → Gets the document within two days, without changing a word of the request. **The same thing is asked of three people and all three reply.** - Addresses the request to one and copies the rest → You get one answer rather than three versions. **Several are asked and none replies.** - Names an owner in the request → Somebody is on the hook. **Two people upload the same document.** - Makes clear who provides what → Duplicated work is avoided. **Each one sends a different version.** - Asks them to coordinate before sending → One version arrives rather than a conflict. **Nobody knows who has already replied.** - Checks the status per recipient → Only those outstanding are chased. --- --- id: KB-CC-016 url: https://app.codecontract.io/help/contacts-and-channels/what-time-to-send idioma: en categoria: contactos-canales audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-002, KB-CO-014] citadoPor: [KB-AD-017, KB-CC-020] --- # What time to send _The same message answered or ignored depending on when it lands, and the hours to avoid._ **Responde a:** best time to send a request · schedule sends for the next day · sending messages out of hours · when to chase a supplier Content decides whether they answer well; timing decides whether they answer at all. It is the cheapest adjustment there is — it changes not a word of the message — and the least used, because almost everything gets sent when the sender has a gap, not when the recipient can deal with it. ## How each moment behaves | When it lands | What usually happens | | --- | --- | | First thing in the morning | Read attentively; it is when outstanding items get cleared | | Just before lunch | Read and deferred, and deferred is forgotten | | Mid-afternoon | Works well for anything needing calm reading | | Friday afternoon | Answered on Monday, if at all | | Out of hours or at weekends | It arrives, it irritates, and it speeds up nothing | > [!IMPORTANT] > The last row matters more than it seems when you write to people rather than companies. A message to a phone on a Sunday night does not bring the reply forward and does leave the impression that you are the disorganised one. If you write it then because that is when you can, schedule it for Monday: the effect on you is nil and on the recipient, considerable. ## What does change the outcome 1. **Schedule instead of sending** — Write when you can and let it go out when it should. That is half this article. 2. **Match the recipient's working day** — A bakery, an accountancy firm and a law office do not start or finish at the same hour. 3. **And do not send two things the same day to the same person** — The second competes with the first and usually both lose. > [!WARNING] > Watch time zones when writing abroad. A send that leaves at nine in your morning lands in the middle of the night across much of Asia and late afternoon in parts of the Americas; and automatic reminders inherit that hour unless scheduled. It is the commonest reason an international campaign gets far less response than the same campaign at home. ## With reminders **En corto** - Spaced out, not daily: daily chasing teaches people to ignore you. - At different times from each other, in case the hour was the problem rather than the message. - And with an end: by the third, it stops being chasing and becomes your decision. > [!NOTE] > Scheduling a send counts as one action, just like sending it now: waiting until Monday costs nothing extra. What does add up is resending the same thing three times because each send landed at an hour when nobody was going to open it. **Is there a magic hour?** No, but first thing in the recipient's morning beats the rest almost always. **What if it really is urgent?** Then the hour is now, and better through a channel that reaches a phone. **Can reminders be scheduled too?** Yes, and it makes sense: let chasing go out at a good hour rather than whenever the clock fired. ## Ejemplos **A company sends its requests on Friday afternoon, which is when it has time.** - Writes them Friday and schedules them for Monday first thing → First-request response rises without changing a word of the message. **The notice goes out on a Friday afternoon.** - Schedules the send for Monday → The notice arrives when somebody can act on it. **The notice arrives in the middle of the night and irritates.** - Sends within reasonable hours → The notice does not create resistance. **It goes out in August and nobody replies.** - Adjusts dates to the sector's calendar → Response rates do not collapse. **It goes to a recipient in another time zone.** - Schedules by their local time → The notice arrives within their working day. **Every notice goes out at the same time and saturates.** - Spreads the sends out → Each notice is read separately. --- --- id: KB-CC-017 url: https://app.codecontract.io/help/contacts-and-channels/when-someone-asks-you-to-stop-writing idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-010, KB-CL-016] citadoPor: [KB-CC-002] --- # When someone asks you to stop writing _Telling apart what you can stop sending from what must still be communicated, and through which channel._ **Responde a:** a contact asks me to stop writing · stop sending reminders to a person · they ask me to call instead of email · removing someone from notifications Sooner or later someone replies to a reminder with "stop writing to me". It may be an irritated individual, an overloaded supplier, or someone who no longer handles that matter. The right reaction is not the same in all three, and confusing them produces either a relationship problem or a breach. ## The three requests that look alike | What they say | What they usually mean | What to do | | --- | --- | --- | | "Stop writing to me" | Stop chasing me about something that is not mine | Find out who handles it and move the request | | "Write to me somewhere else" | Change channel, not stop receiving | Change the channel and record it | | "I do not want you using my data" | Exercising a right, which is different | Treat it as such, not as unsubscribing | > [!IMPORTANT] > The first is by far the commonest and rarely means what it looks like: **the person is not rejecting you, they are telling you that matter is not theirs**. Stopping without finding out who handles it solves nothing — the document still does not arrive and now you do not know who to ask. ## What must still be communicated > [!WARNING] > Some communications are not commercial chasing but part of a relationship: a contractual notice, an expiry warning affecting their access, a notification the contract requires in writing. **Those remain necessary even if the person would rather not receive them**, and what changes is the channel and the tone, not whether they are sent. If someone asks to receive nothing and something must still be communicated, say so explicitly: "I will keep sending you this because the contract requires it". ## How to handle it so nothing is lost 1. **Note it in their record, not in your head** — Unrecorded, the next colleague writes to them again within a month. 2. **Change channel before stopping communication** — Many people who do not want emails will answer a phone message. 3. **And find the replacement in the same conversation** — "No problem, who handles it now?" resolves 80% of cases in one message. ## If it is an individual and it concerns their data **En corto** - It is a request of a different nature and should be treated as such, not as a preference. - It has to be answered, and a record kept of what was done and when. - And not everything can be deleted: what must be retained is retained, and explained. The key is not mixing the two: switching off their reminders and considering a data request handled is what turns a simple matter into a formal complaint. > [!NOTE] > Someone no longer receiving your alerts does not change what you asked them for or the deadlines: the request stays open and keeps running. What changes is how they are chased, not whether they are. **Can alerts be switched off for one contact only?** Yes, and it is worth noting why and since when. **What if they are my only contact at that company?** Then the problem is not the channel: ask for the right contact before you stop writing. **Does changing channel count as an action?** The message you send through the new channel counts like any send; changing the preference does not. ## Ejemplos **An administrator at a supplier replies "stop writing to me" to a reminder.** - They ask who handles it now in the same reply - They record the change in the supplier's record → The request reaches the right person and nobody writes again to someone it never concerned. **Somebody asks not to receive more and is written to anyway.** - Records the request and respects it → The notice stops going out. **The request comes by phone and is not recorded.** - Records the request on the contact → The preference outlives the conversation. **It is respected on one channel and not another.** - Applies the preference across all channels → The request is genuinely met. **You need to write to them about something obligatory.** - Distinguishes the operational from the dispensable → Only what must be sent is sent. **Somebody else at the company does want to receive.** - Records the preference per person → Each one receives what they asked for. --- --- id: KB-CC-018 url: https://app.codecontract.io/help/contacts-and-channels/when-someone-replies-and-it-does-not-register idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-011, KB-CC-015] citadoPor: [KB-CC-003] --- # When someone replies and it does not register _They answered, and for you they are still silent. It is nearly always one of three things, all fixable._ **Responde a:** a supplier says they already replied · the reply does not show in the platform · still getting reminders after replying · replying to a noreply address It is one of the most awkward conversations: you ring a supplier to chase and they tell you, quite rightly, that they sent it two weeks ago. And they did. They sent it — it just landed somewhere it does not count as an answer. ## The three reasons, by frequency | What happened | How it shows | How to avoid it | | --- | --- | --- | | They replied to an automatic notice | The reply appears nowhere | Have the company mailbox connected | | They wrote a new email instead of replying | It arrives, but loose: not tied to what you asked | Ask them to reply to the message, subject unchanged | | They answered from another address | It arrives from someone the address book does not know | Hold the real address of whoever answers, not their boss's | > [!IMPORTANT] > There is a fourth situation, harder to spot, and worth knowing: **if you asked that person for several things at once and they reply without the reference, their answer is tied to the most recent open request**. It arrives, it registers, and it lands in the wrong place: one request looks answered when it is not, and the other keeps chasing. That is why asking for three things in three separate messages is not bureaucracy — it is what makes each answer land where it belongs. ## What to do once it has happened 1. **Ask them to resend by replying to the original message** — Subject untouched: that is where the reference that ties it lives. 2. **If they no longer have it, send again from the platform** — Better a new, properly linked message than one attached by hand. 3. **And note on the card the address they answered from** — It is usually the one they will always use, and it stops the repeat. > [!WARNING] > Before chasing anyone, look at the company mailbox. **What a third party replies lands in your usual email**, and if that mailbox is not connected the platform cannot know anyone answered: it will keep counting the days and sending reminders to someone who already did their part. It is not the supplier's fault, and it is the cause most often mistaken for someone else's neglect. ## How to stop tripping over this **En corto** - One request, one message: answers stop getting mixed up. - Always ask for replies on the same thread, subject unchanged. - Mailbox connected, and checked now and then. - And before chasing by phone, check whether the answer is there and went unseen. > [!NOTE] > Chasing someone who already replied carries a cost that shows up nowhere: next time they take longer, because they no longer assume that sending it achieves anything. **Can I reply to an incoming message?** Yes, and it is best done from the platform so it stays on the same thread. **What if they answer a message by WhatsApp?** It arrives, but elsewhere; say in the message where you want the reply. **Are the attachments they send kept?** They are tied to the request if the message is. Hence the fuss about the subject. ## Ejemplos **A company chases a certificate by phone that the supplier insists was sent.** - Checks the connected mailbox and asks them to resend by replying to the message → The certificate shows up tied to its request, and the supplier stops getting reminders. **Somebody replies by email and it is not on the file.** - Uploads the reply to the file → The history reflects what happened. **The reply lands in one person's inbox.** - Agrees a single channel for replies → Invisible replies disappear. **Somebody who already replied gets chased.** - Checks the file before chasing → An unfair chase is avoided. **The reply comes by phone.** - Records what was said in the file → What was said leaves a trail. **Nobody knows whether a reply closes the request.** - Marks the status on receipt → The file moves on. --- --- id: KB-CC-019 url: https://app.codecontract.io/help/contacts-and-channels/when-the-contact-has-no-email idioma: en categoria: contactos-canales audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-002, KB-CC-014] citadoPor: [KB-CC-004] --- # When the contact has no email _Some people work from a phone alone, and it is not a rare exception: in some trades it is the majority._ **Responde a:** the supplier has no email · requesting documents by whatsapp · I only have a phone number · working with sole traders without email The self-employed haulier, the installer working alone, the farmer, the small village supplier. They generally have an email address, but they do not look at it: their working tool is a phone, and there what works is a message. Treating them as if they had an inbox open all day guarantees no reply. ## Which channel works with whom | Situation | What works best | What to expect | | --- | --- | --- | | Works in an office | Email | A reply within hours or by the next day | | Works on the road or on site | A message to their phone | A fast reply or none | | Has email but never checks it | A message flagging it, email with the detail | They answer the message, not the email | | You must be sure they read it | Message plus a short call | The least popular option and the most effective | > [!IMPORTANT] > What almost nobody accounts for when moving to the phone: **what goes to a phone is read standing up, one-handed**. A message with three paragraphs, two links and a «please find attached» does not get read: it gets postponed. What works there is one sentence saying what is needed and one link, nothing else. The same request that fills half a screen by email has to fit in two lines on a phone — and that rewrite is the difference between getting the document today and chasing it for three weeks. ## How to set it up without overcomplicating 1. **Note on the card where they actually receive things** — Not the channel they gave you: the one they reply from. 2. **One request per message** — On a phone, two requests together is one lost request. 3. **Make it possible to take a photo and send it** — It is all they will do, and it is enough if the photo is legible. 4. **And file whatever they send where it belongs** — Arriving by phone does not mean living on someone's phone. > [!WARNING] > One case worth planning for before it happens: **the number you were given may be personal**. When that person leaves the company, they take the number, the history and the whole thread — and nothing of what was agreed remains with you if it all happened there. So whatever is agreed by message gets copied into the file the same day, even if the conversation carries on wherever suits them. ## When there is genuinely no phone and no email **En corto** - It happens, and it is usually solved by someone acting as a bridge: an agent, a relative, the cooperative. - That intermediary is recorded as such, not as if they were the contact. - And whatever they hand over is traced the same: who contributed it and when. > [!NOTE] > Writing to someone through a new channel has its own rules — consent, hours, and their right to ask you to stop. That is covered separately, and applies to phones as much as to email. **Can I request documents over messaging?** Yes, and it often works better. What matters is where they end up filed. **What if they send a blurry photo?** Ask for a retake there and then: tomorrow they are no longer in front of the paper. **Is calling worth it?** For the important ones, yes. A one-minute call saves four reminders. ## Ejemplos **A company chases a self-employed haulier by email for three weeks.** - Sends one line to their phone with a link and files what arrives in the record → The document lands that afternoon and sits where it belongs, not on someone's phone. **A contact has no email and is left out.** - Uses whichever channel they do have → The notice arrives anyway. **They are messaged and there is no record.** - Records the send in the file → The attempt is documented. **Somebody at their company does have email.** - Asks for an alternative contact → The request gets in where it can. **They only answer the phone.** - Calls and records what was said → The file moves with a record. **It is assumed you cannot work with them without email.** - Adapts the channel rather than dropping them → The supplier stays in the circuit. --- --- id: KB-CC-020 url: https://app.codecontract.io/help/contacts-and-channels/when-an-auto-reply-comes-back idioma: en categoria: contactos-canales audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-014, KB-CC-016] citadoPor: [KB-CC-012] --- # When an auto-reply comes back _«I am away until the 30th» looks like an obstacle and is the opposite: the one time they tell you who to ask._ **Responde a:** the contact is on holiday · out of office reply · who do I write to if they are away · message returned as absent You send the request and back comes a message saying that person is away for two weeks. The normal reaction is to note it mentally and write again when they return. That wastes the useful part: nearly all those replies carry a name and an address you did not have. ## What to do with each kind of auto-reply | What it says | What it means | What to do | | --- | --- | --- | | «I am away, write to X» | They are handing you a new contact | Write to X and record it on the card | | «I am away» and nothing more | Nobody covers, or they will not say | Try another channel if it is urgent | | «I no longer work here» | The record is out of date | Update it today, not at clean-up time | | «This mailbox is not monitored» | You were writing to a wall | Change address before chasing | > [!IMPORTANT] > The third and fourth deserve same-day attention: **an auto-reply is the only way an out-of-date record tells you it is out of date**. Nobody will write to say that address no longer works; only the system on the other side says it, once, in a message that is usually filed unread. Ignore it and that address keeps receiving requests nobody reads for months, while the file looks stalled through the supplier's fault. ## What to do when there really is no cover 1. **Check whether the return date fits what you need** — If they are back in three days, often nothing else is needed. 2. **If it does not, look for someone else at the company** — The email domain tells you who else you hold. 3. **And when you write, explain why it reached them** — «X is away and this is due on the 10th» stops a bare forward. 4. **Reschedule whatever can wait** — Better received when it can be dealt with. > [!WARNING] > On chasing someone who has said they are away: **automatic reminders keep going out even after the machine replied**. That person comes back from holiday to four of your reminders stacked on the original request, all dated after their absence notice. It is not merely rude: it is what makes them slower to answer next time. When an absence notice arrives, pause the chasing until the return date. ## What is worth harvesting from that message **En corto** - The name and address of whoever covers, even if you do not need them today. - The return date, so you do not write three times meanwhile. - And the fact that this person is — or is no longer — at the company. > [!NOTE] > If the auto-reply says they have left and gives a new contact, record it as a change of person rather than editing the card over the top: the history must still say who was written to at the time. **Can I ask the cover for the same thing?** Yes, with context: they almost never know what it is about. **What if the absence outlasts the deadline?** Write to the cover or the company: deadlines do not pause themselves. **Is the cover worth saving?** Yes: next year they will be away over the same dates. ## Ejemplos **A company gets an out-of-office notice and lets reminders keep firing for two weeks.** - Pauses chasing until the return date and writes to the cover named in the message → The document arrives sooner and the supplier does not return to four stacked reminders. **An out-of-office auto-reply comes back.** - Records the return date and reschedules → The notice arrives when they can act on it. **The auto-reply names another contact.** - Updates the contact with the substitute → The request reaches somebody who can act. **The auto-reply is taken for an answer.** - Distinguishes the automatic from the human → The file's status is true. **Chasing continues towards somebody on leave.** - Pauses the chase until they return → No effort is spent into the void. **The auto-reply says the address no longer exists.** - Updates the contact on receipt → Notices stop getting lost. --- --- id: KB-CC-009 url: https://app.codecontract.io/help/contacts-and-channels/calling-people-automatically idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-002, KB-CF-005] citadoPor: [KB-CC-014] --- # Having the system phone people _For people who read no email and answer no messages, but do pick up the phone._ **Responde a:** automatically call a supplier · voice channel to request data · the supplier reads no email or sms · automated call with transcription Some of the people you work with read no email, answer no texts, and still pick up the phone every time. For them there is another channel: the system calls, asks the question, listens to the answer and stores it. ## What exactly happens on a call 1. **It dials the contact** — On the number in their record. Without one, this channel cannot be used. 2. **It plays what you are asking** — The text you wrote, not a generic recording. 3. **It transcribes the answer** — What the person says is turned into text. 4. **It stores it as evidence** — Recording and text stay in the case, with their date. > [!IMPORTANT] > This channel is for requesting DATA, not documents. Someone can tell you a policy number or confirm a date by phone; they cannot hand you a PDF by speaking. For documents, use another channel. ## When it pays off | Situation | Call? | | --- | --- | | A specific value is missing and they do not answer in writing | Yes, this is its case | | Something needs confirming urgently | Yes | | A document is missing | No, a call cannot collect it | | The contact has no phone number on record | Not possible | | It is your first contact with them | Better not: an automated call from a stranger breeds distrust | > [!WARNING] > A call consumes considerably more than an email or a message: dialling, transcribing and storing each count separately. It is the heaviest-consuming channel of all, which is why it is best kept for when the others have already failed. > [!NOTE] > There is an hourly call limit. It is not arbitrary: repeatedly calling the same number in a short window is harassment, however it looks from this side. ## Before using it **En corto** - Write the text as you would say it to a person, not as a form. - Say who you are in the first sentence, or they will hang up. - Use it once email and SMS have failed, not before. **Can I listen to the recording?** Yes, it stays in the case with the transcription. **What if they do not answer?** The attempt is logged with its time. **Can it be used for many contacts at once?** It is an expensive channel with hourly limits; it is meant for specific cases, not campaigns. ## Ejemplos **A self-employed haulier has ignored email for three weeks and their policy number is missing.** - The voice channel calls asking for that value - The answer is transcribed into the case → The case closes that day, with the answer recorded and dated. **A supplier reads neither emails nor messages.** - Uses the automated call as a last resort → The notice arrives where they do respond. **Thirty suppliers are phoned by hand.** - Lets the call go out on its own → The team does not spend the morning dialling. **The call happens at an inconvenient hour.** - Schedules the call within reasonable hours → The notice does not intrude. **There is no record that a call was made.** - Records the call and its outcome → The attempt is documented. **A call is made without trying in writing first.** - Reserves the call for when the rest failed → The channel is used where it adds. --- --- id: KB-CC-004 url: https://app.codecontract.io/help/contacts-and-channels/writing-a-message-people-understand idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-002, KB-PR-003, KB-CC-019] citadoPor: [KB-CC-010, KB-CC-012, KB-CC-007] --- # Writing a message people understand _What decides whether a third party acts today or leaves it forever._ **Responde a:** how to word a document request · email template to request documentation · the supplier does not understand what i want · improve notice wording The notice is read by someone outside your context, probably on a phone, among twenty other things. They have ten seconds to work out what you want and why it matters to them. **En corto** - Say who you are before what you want. - Name the document by its full official name. - Say by when, and what happens if it does not arrive. ## The structure that works 1. **Who and why** — "We are X, we work with you on the Y site." Without this, the rest goes unread. 2. **What you need, specifically** — "The social security clearance certificate", not "the outstanding documentation". 3. **By when** — A real date. "As soon as possible" is not a date. 4. **What it unblocks** — "With this we can register you and start paying invoices." It gives them their own reason. ## What sinks a message | Mistake | What it causes | | --- | --- | | Subject in capitals or with "URGENT" | Filters send it to spam | | Internal names: "doc 3", "phase B" | They do not know what you want | | Three paragraphs of context | They do not get past the first | | No date | They leave it for later, and later never comes | > [!WARNING] > Do not write anything resembling an automated threat ("failure to comply will result in…"). The recipient is not a debtor: usually they are someone who did not know you had asked. > [!NOTE] > Read it aloud before sending it to two hundred people. What cannot be read aloud without sounding odd does not read well on screen either. **Can I save wording that works?** Yes, as a reply template, so it is not rewritten each time. **Do I sign with my name or the company's?** Both. A personal name raises response. **Which language for a foreign supplier?** Theirs if you can; otherwise English, with the document name also in theirs. ## Ejemplos **A notice asks for "the outstanding phase 2 documentation" and nobody replies.** - Rewrites it naming the three documents - Adds a date and what it unblocks → Eleven of fifteen suppliers deliver within forty-eight hours. **The message uses internal jargon and nobody understands it.** - Rewrites it for somebody who does not know you → Clarification calls drop. **The message does not say when it is needed by.** - Includes the specific date → The recipient prioritises sensibly. **The message does not explain why it is being requested.** - Adds a line of context → People reply without asking first. **The subject looks like marketing and is not opened.** - Writes a specific subject → The email gets opened. **The message asks for five things in one paragraph.** - Lists them one by one → The recipient sees what is theirs. --- --- id: KB-CC-005 url: https://app.codecontract.io/help/contacts-and-channels/importing-contacts-from-your-system idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-003, KB-ET-004] citadoPor: [KB-CC-015] --- # Bringing in the contacts you already have _Start from the list you already have, without typing anyone in._ **Responde a:** import contacts from a spreadsheet · upload the supplier list · migrate contacts from another system · bulk load clients Nobody starts from zero: the supplier or client list already exists somewhere, even if only in a spreadsheet. Bringing it in whole takes half an hour and avoids the slowest possible start, which is typing two hundred contacts. ## What the list needs **En corto** - Company name and person's name. - Email, and mobile if you have it. The mobile is what you will be most grateful for later. - Your own identifier, if you use one, so it can be cross-referenced with your system. ## Half an hour well spent before importing 1. **Remove duplicates: the same person twice becomes two records with split histories.** 2. **Remove people who have left: dead addresses gain you nothing.** 3. **Check the columns: an email in the phone column is spotted by your eye before the system's.** > [!WARNING] > Importing a dirty list does not clean it: it relocates it. From then on the bounces show up inside cases, when they get in the way. > [!NOTE] > If you have ten years of contacts, bring only the active ones. The rest can be imported later if needed, and meanwhile they do not clutter searches. > [!IMPORTANT] > That list holds personal data about people who did not choose to be in your new tool. Bring what you need to work — name, email, professional contact number — and do not drag along fields you will never use just because they were in the file. **Can I re-import to update?** Yes, and existing records are updated rather than duplicated. **What if my system does not export to a spreadsheet?** Almost all do. Failing that, it can come in through the API. **Are contacts notified when imported?** No. Importing sends nothing; notices go out when you launch something. ## Ejemplos **A company has 340 suppliers in an eight-year-old spreadsheet.** - Filters the 190 with recent activity - Removes 24 duplicates - Imports those 190 → Starts working that same afternoon without typing a single contact. **An old list is imported and half of it bounces.** - Cleans it before importing → The first campaign does not start on bounces. **Contacts are imported with no company attached.** - Attaches each contact to their company → The contact is usable. **It is imported twice and contacts duplicate.** - Checks for duplicates after importing → Nobody receives the same thing twice. **The data comes in columns that do not match.** - Reviews the mapping before importing → The phone number does not end up in the job-title field. **Everything is imported and the address book becomes unmanageable.** - Imports only what is used → The address book stays useful. --- --- id: KB-CC-006 url: https://app.codecontract.io/help/contacts-and-channels/what-a-contact-is-and-what-it-does idioma: en categoria: contactos-canales audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-002, KB-CC-003] citadoPor: [KB-CC-008, KB-ET-012] --- # What a contact is _The record of someone outside, and why it pays to keep it right._ **Responde a:** what is a contact on the platform · why create a contact · difference between a contact and a user · how do i add a supplier A contact is someone outside your organisation that you deal with: a supplier, a client, a subcontractor's worker, a signer. They have no account, do not enter the platform, and see nothing beyond what you ask them for. **En corto** - A contact is not a user: they do not sign in, do not use a licence and do not see your work. - It stores how to reach that person and what has happened with them. - Kept right, it is what makes a notice land first time. ## Contact and user, which get confused | How they differ | Contact | User | | --- | --- | --- | | Who they are | Someone outside | Someone on your team | | Signs in | No | Yes | | Sees your cases | Only their own part, by link | Whatever their permissions allow | | Needs an invitation | No | Yes | ## What is worth storing - The person's name and their company's. A notice addressed to a person gets opened more than one addressed to "info". - Email, and their mobile if you have it. The mobile is what saves you when email bounces. - The language you will write to them in, if it is not yours. > [!NOTE] > Asking for the mobile at first contact costs one line and saves weeks later. By the time you need it — because email bounces or there is a rush — there is nobody to ask. **Do contacts cost anything?** No. Only what you send them consumes, not storing them. **Can I have several contacts at the same company?** Yes, and you should: one for paperwork, another for invoicing. **Do they know I created them?** No. Creating a contact sends nothing. ## Ejemplos **A company stores only each supplier's generic email address.** - Adds the specific person and their mobile at first contact → Notices stop dying in an inbox nobody reads and delivery rises without changing anything else. **The contact is confused with the company.** - Records the company and the people separately → Each relationship has its own contact. **One contact serves two companies.** - Keeps one record per company → The history does not mix. **A generic mailbox is stored as the contact.** - Asks for a specific person → The request reaches somebody who can act. **Nobody knows what role each contact has.** - Records their function at the company → You write to the right person. **The contact is stored with no phone number.** - Completes the record at first dealings → Changing channel is possible when needed. --- --- id: KB-CC-007 url: https://app.codecontract.io/help/contacts-and-channels/writing-to-third-parties-in-their-language idioma: en categoria: contactos-canales audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-004, KB-CC-002] citadoPor: [KB-DI-013] --- # Writing to third parties in their language _What actually changes when the supplier does not speak your language._ **Responde a:** request documents from a foreign supplier · what language to write to an overseas supplier · translate notices to another language · international supplier documentation A supplier who does not understand what you are asking for is not an uncooperative supplier: they are a supplier who has not understood. The difference matters, because one is solved by chasing and the other is not. **En corto** - The document's name in their language is worth more than the whole email translated. - English works as a bridge, but not for naming official documents. - What gets signed is read in the language it is signed in. ## What to translate, in order | What | Priority | Why | | --- | --- | --- | | The document's name | Highest | It is the only thing they have to find in their files | | The deadline and what it unblocks | High | It is their reason to act today | | Context about who you are | Medium | English usually suffices | | The document they sign | Mandatory where it has effects | Nobody should sign what they cannot read | > [!IMPORTANT] > If the document being signed has legal consequences, having it in a language the person understands is not courtesy: a signature on text the signer could not read is exactly what gets disputed later. ## The trick that pays off most Put the official document name in their language **and** in yours, in brackets. They find the paper; you still know what you are being sent when it arrives. > [!WARNING] > Be careful translating official document names literally: the equivalent certificate in another country is called something else, and sometimes does not exist. Better to describe what it attests than to invent a name. > [!NOTE] > The help centre is in six languages precisely for this: you can link them the article explaining what a case is in their own language instead of explaining it yourself. **Can I keep templates per language?** Yes, saved as reply templates. **What if I do not know their language?** The company's country language is nearly always right; English is the fallback. **Does automatic reading work on documents in other languages?** Yes, including non-Latin scripts. ## Ejemplos **A company has had nothing from a Portuguese supplier for three weeks.** - Rewrites the request naming each document in Portuguese and in Spanish - Links them the help article in Portuguese → They deliver in two days; it was never reluctance, they simply did not know what was being asked. **A foreign supplier is written to in your own language.** - Sends the notice in their language → Response rates rise. **The link leads to a screen in another language.** - Checks how the recipient sees it → The path is understood on the other side. **The message is translated but not the document names.** - Also translates what is being requested → The supplier knows what to send. **The language is assumed from the company's country.** - Records the contact's language → The notice goes out in the right language. **A contact replies in another language.** - Updates their language on the record → Later sends already go out right. --- --- id: KB-CC-001 url: https://app.codecontract.io/help/contacts-and-channels/channels-email-sms-and-whatsapp idioma: en categoria: contactos-canales audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-003, KB-TL-004, KB-ET-001] citadoPor: [KB-CC-003, KB-PR-003, KB-CC-011, KB-DI-014, KB-CC-002] enLaApp: https://app.codecontract.io/settings/notifications --- # Channels: email, SMS and WhatsApp _How notices arrive, why they end up in spam and how to raise response rates._ **Responde a:** why do my emails go to spam · send notices by whatsapp instead of email · set up SMS notifications · message templates for requesting documents · improve supplier response rates It does not matter how well the process is built: if the notice does not arrive, or arrives and is not read, nobody delivers. Most "this supplier never replies" cases are a channel problem, not a willingness problem. **En corto** - Email is the default channel and the one most likely to land in spam. - Connecting your own domain is the single biggest improvement to delivery. - SMS and WhatsApp reach the phone and get read; email competes with a hundred others. - Switching channel on the second reminder is what works best. ## Which channel, and when | Channel | When it fits | What to watch | | --- | --- | --- | | Email | First notice, long documents, office recipients | It crosses the most filters; without your own domain, half never arrives | | SMS | Reminders, field staff, signature codes | Costs credits; the text is short, so the link must be clean | | WhatsApp | Sole traders, small suppliers, anyone who ignores email | Very high read rate; the mobile number has to be right | _The combination that works best: email first, second reminder by WhatsApp or SMS._ ## Why email ends up in spam An email claiming to come from your company but sent from a different domain is exactly the pattern anti-phishing filters look for. Connecting your email account makes the notice go out from your domain; and if your authentication records are in order, it lands in the inbox. > [!WARNING] > If they still land in spam after connecting your email, an authentication record is almost always missing from your domain's DNS. Whoever administers it fixes that once and for all. ## The wording matters too - A message written by you gets noticeably more replies than the generic one. - Saying what it is for and by when cuts the questions that come back. - Each request title is read by someone outside: "Doc 3" means nothing. - Message templates save rewriting it each time without losing that tone. ## Frequently asked questions **Can I notify on several channels at once?** Yes, if you hold the details. One is usually enough for a first notice; combined channels pay off on reminders. **How do I know the notice arrived?** The case flags the send, the bounce and the link opening. That separates "it never arrived" from "they have not looked". **Do SMS and WhatsApp cost?** Yes, they consume credits because the carrier charges. Email does not. **What language is it sent in?** The contact's, from their record. Not yours, which is the common wrong assumption. ## Ejemplos **A company sends 80 requests by email and after five days only 20 have replied.** - Checks how many emails were opened on the cases: only 25 - Connects their email domain and resends to those who never opened - Sets the second reminder on WhatsApp → Goes from 20 to 63 replies in a week, without changing a word of the text. **The email does not arrive and people keep emailing.** - Changes channel after the second attempt → The notice arrives where it gets read. **A supplier only responds on messaging.** - Sends them the link on that channel → Uses the channel they already use. **Everything goes out on the same channel out of habit.** - Picks the channel by urgency and recipient → Delivery improves without more chasing. **Nobody knows whether the message arrived.** - Checks the delivery status → Sent is told apart from delivered. **A channel the recipient does not want is used.** - Records each contact's preferred channel → The notice arrives where it gets handled. --- --- id: KB-CC-002 url: https://app.codecontract.io/help/contacts-and-channels/which-channel-for-which-message idioma: en categoria: contactos-canales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-001, KB-PR-003, KB-CC-017] citadoPor: [KB-CC-003, KB-TD-002, KB-TD-009, KB-CC-011, KB-CC-013, KB-CC-016, KB-CC-019, KB-CC-009, KB-CC-004, KB-CC-006, KB-CC-007] --- # Which channel for which message _Email, SMS or WhatsApp: which arrives, which annoys, and which costs._ **Responde a:** best channel to request documents · when to use whatsapp instead of email · send notices by sms · the client does not read emails The same message performs differently depending on the route. It is not a matter of taste: each channel has a place where it is read and a threshold for what counts as intrusive. | Channel | Read | Cost | Good for | | --- | --- | --- | --- | | Email | When the inbox is opened | Same as the others | Anything with documents that needs reading properly | | SMS | Almost immediately | Same | Urgent things, and reaching people who do not use email | | WhatsApp | Immediately | Same | Third parties you already talk to there | ## The practical rule - Start with email: it costs the same as any other channel and carries detail. - Escalate to SMS when email did not arrive or there is genuine urgency. - Use WhatsApp only if you already have that relationship; otherwise it reads as intrusion. > [!WARNING] > Sending the same notice on all three channels at once does not triple delivery: it reads as harassment, and the first time you do it you will earn a block. ## When to switch channel If the notice was opened and there is still no reply, switching channel adds nothing: the message arrived. Switching helps when the previous one did not arrive — a bounced email, or three unopened notices. > [!NOTE] > For people working on site or on the road, email arrives late and a phone always arrives. There, SMS is not chasing: it is the right channel from the start. **Can I choose the channel per contact?** Yes, and it is worth it for the ones you know do not read email. **What if I do not have their mobile?** Only email remains. Asking for the mobile when creating the contact saves weeks later. **Does WhatsApp have to be a business number?** Yes, a verified one. A personal number inspires no confidence and cannot be audited. ## Ejemplos **A construction firm cannot get paperwork from site managers who never open email.** - Sets SMS as the preferred channel for that group → Delivery goes from days to hours, because the notice lands where that person actually looks. **An urgent notice goes by email and is read the next day.** - Uses a more immediate channel for what is urgent → The urgency arrives in time. **A long link is sent by message and gets truncated.** - Sends the link on a channel that preserves it → The link arrives whole. **Sensitive documentation goes out on any channel.** - Uses the channel that matches the content → Sensitive material travels where it should. **Channels are combined and the recipient gets three notices.** - Defines one channel per notice type → Nobody receives the same thing three times. **The channel is chosen without knowing what the recipient uses.** - Asks or records their preference → The first send already works. --- --- id: KB-AD-004 url: https://app.codecontract.io/help/administration/what-to-look-for-in-the-activity-log idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-TZ-003] citadoPor: [KB-AD-015, KB-AD-016, KB-AD-019, KB-GL-014] --- # What to look for in the activity log _Ten minutes a month, and exactly what to look at._ **Responde a:** see who did what · platform audit log · who downloaded that document · detect improper access The log records everything, which is why reading all of it is useless. What works is looking at four specific things, once a month. ## The four - Accounts still active for people who have left. - Bulk downloads: someone taking far more at once than their work requires. - Access at times or from places that do not fit that person. - Permission changes nobody remembers making. | What you see | What it usually is | What to do | | --- | --- | --- | | 400 documents downloaded on a Friday | Someone preparing an audit… or leaving | Ask, without accusing | | Access at 4am | Almost always a different time zone | Check who and from where | | A permission widened for no reason | A change made in a hurry and never reverted | Review it and set it back | > [!IMPORTANT] > Finding something odd is not accusing anyone. The vast majority of what stands out has an ordinary explanation, and asking before concluding is what makes this habit sustainable in a small team. ## When to look properly When someone leaves on bad terms, when there is a dispute, or when something does not add up. That is when the log stops being hygiene and becomes the thing that answers the question. > [!WARNING] > The log cannot be edited, and that is deliberate: a log an administrator could retouch would prove nothing. **How long is it kept?** According to your retention policy. **Can it be exported?** Yes, for an audit or for your adviser. **Can non-administrators see it?** No. It is sensitive information about the people on your team. ## Ejemplos **An administrator reviews the log and finds two active accounts for people who left months ago.** - Closes them - Checks they were not used since → Ten minutes of review close two doors that had been open for half a year. **The log is only looked at when there is a problem.** - Reviews what matters regularly → The odd thing shows before the incident. **Access appears at an unusual hour.** - Checks with the person before raising the alarm → The anomaly is explained or acted on. **Somebody downloads many documents at once.** - Checks what and why → The movement is understood. **An auditor asks for evidence of oversight.** - Shows the reviews performed, with dates → Oversight is demonstrable. **The log has too much noise to read.** - Filters by what actually matters → The review is manageable. --- --- id: KB-AD-005 url: https://app.codecontract.io/help/administration/signing-in-with-your-company-account idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-ET-005] citadoPor: [KB-AD-001] --- # Signing in with your company account _One password fewer, and leavers are handled automatically._ **Responde a:** configure single sign-on · sign in with microsoft or google · stop users needing another password · automatically provision users If your people already sign in to everything with their work account, giving them one more password makes little sense. Single sign-on removes it, and along the way fixes the thing nobody remembers: closing access when someone leaves. **En corto** - One fewer password to manage, forget and reuse. - Your security rules — expiry, two-factor — apply here too. - Deactivating someone in your system removes their access here. ## What changes most It is not the convenience of signing in: it is the leaver. An account still open six months after someone left is the commonest security failure in small companies, and with single sign-on it stops depending on somebody remembering. | Without it | With it | | --- | --- | | One more password per person | The usual one | | Leavers handled manually, if remembered | Applied automatically | | Your password policy does not reach here | Applies as it does everywhere else | > [!IMPORTANT] > Before enabling it, make sure at least one administrator has an alternative way in. If your identity provider goes down and nobody can sign in, you need a service door. > [!WARNING] > Single sign-on does not distribute permissions on its own: it says who you are, not what you can do. Permissions are still decided here. > [!NOTE] > It is worth it from ten or fifteen people upward. Below that, managing accounts by hand costs less than configuring it. **Does it work with Microsoft or Google?** With the usual identity providers, yes. **What about people without a work account?** It can coexist with normal sign-in for specific cases. **Do third-party signers come in this way too?** No. They have no account and do not need one. ## Ejemplos **A seventy-person company finds five open accounts belonging to people who left.** - Enables single sign-on - Keeps an alternative route for two administrators → Later leavers are cut off the same day without anyone having to remember. **Everyone signs in with a different personal account.** - Uses the corporate account to sign in → Joining and leaving follow the company. **Somebody leaves and their access depends on a personal address.** - Ties access to the company account → Departure cuts access. **Passwords are forgotten constantly.** - Signs in with the account they already use daily → There stops being one more password. **Somebody signs in with two different accounts.** - Merges into the corporate one → The history stops splitting. **The corporate domain changes.** - Updates the configuration before the change → Nobody is locked out on the day. --- --- id: KB-AD-006 url: https://app.codecontract.io/help/administration/inviting-someone-from-your-team idioma: en categoria: administracion audiencia: administrador nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-AD-002] citadoPor: [KB-AD-007, KB-AD-011, KB-ET-011] enLaApp: https://app.codecontract.io/settings/members --- # Inviting someone from your team _How to add a colleague, and what to decide before clicking invite._ **Responde a:** how do i invite a colleague · add users to the account · give access to someone in my company · my colleague did not get the invitation Inviting someone takes thirty seconds. What deserves a minute's thought is what they will be able to do, because changing it later is more awkward than getting it right first time. ## How to do it 1. **Go to Settings → Members.** 2. **Click "Invite" and enter their work email.** 3. **Choose what they will be able to do.** 4. **Send. They receive an email to sign in and set their password.** ## What to decide first | Question | Criterion | | --- | --- | | Do they need to change settings? | If not, do not make them an administrator | | Do they need to delete? | Almost never. It is the permission that does most damage | | Do they need to see everything? | If they work in one area, scope them to their team | > [!IMPORTANT] > Two administrators, not one and not five. With only one, if that person loses access nobody inside can fix it; with five, nobody feels responsible for anything. ## If the invitation does not arrive - Check the address is spelled correctly: that is 90% of cases. - Have them check spam. - Resend it; the previous link still works. > [!NOTE] > Invite when there is something to show. Signing in to an empty account engages nobody; signing in to a process that already works does. **Does having more people cost anything?** It depends on your plan; check before inviting twenty people. **Can non-administrators invite others?** No, and it is better that way. **Can what they do be changed later?** Yes, at any time. ## Ejemplos **A company invites all five team members on day one and nobody signs in.** - Waits until one process is working - Invites them again with something to show → All five sign in that week because there is something concrete to do inside. **Somebody is invited without deciding their permissions.** - Picks the role when inviting → They come in able to work and without seeing too much. **The invitation goes unaccepted for weeks.** - Checks the pending invitations → Onboarding is closed or withdrawn. **The invitation goes to a personal address for convenience.** - Uses the corporate address → Departure cuts access. **Somebody joins and nobody shows them where to start.** - Points them at the process they will use → Day one is useful. **Somebody who only had to provide one document is invited.** - Sends them a link instead of inviting them → No licence is consumed for one contribution. --- --- id: KB-AD-007 url: https://app.codecontract.io/help/administration/what-to-do-if-you-suspect-unauthorised-access idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-AD-006, KB-AD-016] citadoPor: [KB-AD-009, KB-AD-012, KB-AD-019] --- # If you suspect someone got in _The first twenty minutes, in order, and who to tell._ **Responde a:** i think someone accessed our account · unauthorised access what do i do · an employee's password was stolen · close open sessions The instinctive reaction is to investigate first. It is the wrong one: while you investigate, whoever got in is still inside. The right order is close, then look, and notify in parallel. ## The first twenty minutes 1. **Close that account's sessions** — And change its password. It is the only urgent thing; everything else can wait ten minutes. 2. **Enable or require two-factor** — If it was not on, that is how they got in. A stolen password without a second factor opens the whole door. 3. **Read that account's log** — What was opened, what was downloaded and from where. Now it is time to investigate. 4. **Notify the right people** — The affected person, and whoever handles data protection if third-party data was reached. ## What to look for in the log | Signal | What it usually means | | --- | --- | | Bulk downloads | Someone taking information, not a mistake | | Access from a place or time that does not fit | Check first whether that person was travelling | | Permission changes | An attempt to keep access after you close it | | A contact or bank account modified | Fraud in progress: check this before anything else | > [!IMPORTANT] > If third parties' personal data was reached — payroll, identity documents, client files — there may be notification duties on short deadlines. Tell whoever handles data protection that same day, even before you know the scope. > [!WARNING] > Do not delete anything while investigating, not even to tidy up. The log is what lets you know what happened and prove how you responded. > [!NOTE] > The commonest cause is not a sophisticated attack: it is a password reused on another service that leaked. Which is why mandatory two-factor is the measure that returns most for how little it costs. **Can I see whether they downloaded anything?** Yes, accesses and downloads are logged. **Do I notify affected clients?** That decision is not only technical. Let data protection make it with your adviser. **What if it was a false alarm?** All the better. Closing one session too many costs one person a minute. ## Ejemplos **An employee reports an odd access alert on their account.** - Their sessions are closed and the password changed - Two-factor is made mandatory for the whole organisation - Their log is reviewed: nothing was downloaded → The scare closes in half an hour and the organisation comes out with protection it did not have before. **Access appears from an unexpected location.** - Closes the sessions and changes the password → Access is cut while it is investigated. **There is a suspicion and nobody knows what was touched.** - Checks that session's log → The scope becomes known. **Raising it is delayed out of uncertainty.** - Raises it anyway and documents the suspicion → The response does not wait for certainty. **The second factor was switched off.** - Turns it on for everyone after the incident → The cause is closed. **There is no record of what was done.** - Records what was done and when → The incident can be explained. --- --- id: KB-AD-008 url: https://app.codecontract.io/help/administration/teams-when-and-how-to-split-them idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-ET-005] citadoPor: [KB-AD-010] --- # Teams: when to split the organisation _Splitting too early gets in the way; splitting late leaves everyone seeing everything._ **Responde a:** when to create teams · separate work by department · everyone sees every case · organise teams by site or by area Teams separate who sees what. With five people they are overhead; with forty and three departments they are necessary. The signal is the answer to one question: is anyone seeing something they should not? | Situation | Teams | Why | | --- | --- | --- | | Under ten people, everyone does everything | No | Splitting makes sharing templates and contacts harder | | Departments with different sensitive material | Yes | HR has no need to see purchasing, or the reverse | | Several sites or clients with their own teams | Yes, one per site or client | It is also what lets you scope an auditor's access | | Clients who compete with each other | Mandatory | Not convenience: it is third-party information | > [!IMPORTANT] > If you hold documents for competing clients, one team per client is not an organisational preference. Broad permissions there expose a third party's information without their authorisation. ## What stays shared anyway **En corto** - Contacts and templates: no need to duplicate them per team. - The credit balance, which belongs to the organisation. - Settings and branding. > [!NOTE] > Start without teams and add them when someone asks why they can see something. Splitting later is easier than merging what was split too far. **Can someone be in two teams?** Yes, and it is normal for coordinators. **Does an administrator see every team?** Yes. Which is why there should be two, not nine. **Can a case move between teams?** Yes, keeping its history. ## Ejemplos **A 25-person firm serves two clients in the same sector.** - Creates one team per client - Scopes each account manager's permissions → No manager sees documents belonging to the client that competes with theirs. **Everyone sees everything and there are now forty people.** - Separates into teams according to the work → Each one sees their own. **The organisation is split and templates have to be duplicated.** - Considers whether permissions would have sufficed → The structure does not multiply without reason. **One team needs to see another's work occasionally.** - Grants access to the specific file → The exception does not break the separation. **Reports have to be added up by hand across teams.** - Queries the whole from above → The overall picture exists. **It was separated out of caution and now it gets in the way.** - Revisits the decision with usage data → The structure matches how people work. --- --- id: KB-AD-009 url: https://app.codecontract.io/help/administration/what-happens-if-you-lose-your-administrator idioma: en categoria: administracion audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-AD-007] citadoPor: [KB-AD-020] --- # If you lose your administrator _The scenario nobody prepares for, and that blocks the whole organisation._ **Responde a:** our only administrator left · nobody can change the settings · recover control of the account · the administrator lost access The organisation keeps working: people sign in, cases progress, third parties deliver. What cannot be done is anything requiring an administrator — inviting someone, changing a permission, topping up, closing the account of whoever left. And that is discovered exactly when it is needed. ## The three scenarios | What happened | Severity | How you get out | | --- | --- | --- | | The administrator lost their second factor | Low, if there is another | The other administrator restores it | | They left the company and nobody took over | High | It needs handling from outside | | They were the only one and are uncontactable | Very high | This is the case to prevent, not to solve | > [!IMPORTANT] > All three are prevented by the same five-minute measure: **two administrators, always**. Not one in case they fail, nor five, because then nobody feels responsible. Two people who know each other and will not leave on the same day. ## What to have ready **En corto** - Two administrators, and both aware of it. - Two-factor recovery codes, kept where one person cannot lose them. - And someone else knowing who handles the commercial relationship, for what cannot be solved internally. > [!WARNING] > When someone leaves the company, check whether they were an administrator **before** closing their account. Closing it while they are the only one creates the problem, with the added twist that you can no longer ask them to hand anything over. ## In the meantime Whatever does not require an administrator keeps working: requesting, signing, reviewing, closing cases. What is blocked is managing the account itself. Knowing that avoids the panic of thinking everything has stopped when what has stopped is one specific part. > [!NOTE] > It is the five-minute check that returns most in the whole of administration: look at how many administrators exist right now. If it is one, fix it today. **How many administrators is right?** Two. One is risk, many means nobody takes responsibility. **Can an administrator appoint another?** Yes, and that is exactly what to do today if you are one. **Is anything lost meanwhile?** No. Work continues; what stops is account management. ## Ejemplos **A company discovers its only administrator left a month ago when trying to invite someone new.** - Recovers control with outside help - Appoints two administrators → A lost week that the five-minute check would have prevented. **The only administrator leaves the company.** - Names a second before it happens → The account is not left ungoverned. **The administrator is unreachable and a change is needed.** - Keeps two administrators active → Work does not stop. **The problem is discovered once there is nobody left.** - Reviews who is an administrator periodically → The gap shows sooner. **A second is named and nobody explains what they do.** - Gives them access and context from the start → The deputy is genuinely useful. **Administration notices go to a single address.** - Addresses notices to both → The notice reaches somebody who can act. --- --- id: KB-AD-010 url: https://app.codecontract.io/help/administration/when-the-team-grows-from-five-to-fifty idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-ET-011, KB-AD-008] citadoPor: [KB-AD-017] --- # When the team grows from five to fifty _What worked with five people stops working, and gives no warning._ **Responde a:** organising the platform as the team grows · everyone is an administrator and we are now many · reorganising permissions in a growing company · scaling document management With five people everything works with nothing configured: everyone sees everything, everyone can do anything, and if something goes wrong you talk it out. That model holds up to a point and then stops working without warning — usually between fifteen and twenty-five people. ## The signs you are no longer five | Sign | What is happening | | --- | --- | | Someone deletes something by accident | Too many people with delete permission | | Nobody knows who owns a case | No owner, and with five it was not needed | | People ask on chat who did what | The log exists, but nobody uses it yet | | A colleague sees something they should not | Teams need separating | | There are seven administrators | Nobody feels responsible for anything | > [!IMPORTANT] > None of these signs is a tool failure: they are the five-person model applied to twenty-five. And none resolves itself, because individually each looks like an isolated case. ## The order to fix it in 1. **Reduce to two administrators** — Fastest, and removes the most risk. Half an hour. 2. **Remove delete permission from whoever does not need it** — Almost nobody needs it daily, and it does the most damage. 3. **Give cases an owner** — One per case, by name. It is what prevents dead cases. 4. **Separate into teams if something should not be seen by all** — And only then: splitting before it is needed gets in the way. > [!WARNING] > Do not do it all in one day or without warning. Removing permissions without explaining why reads as distrust, and people remember that longer than the improvement lasts. > [!NOTE] > The natural moment is when someone new joins and you do not know what permissions to give them. That doubt is the signal: it means there is no longer one profile that fits everyone. **When exactly is the right time?** There is no magic number. The signal is doubt about a new joiner's permissions. **Can it be reversed?** Yes, everything adjusts. But explain changes rather than making them silently. **What if we grow very fast?** Then start with two administrators and delete permission; the rest can wait. ## Ejemplos **A company grows from 8 to 30 people in a year and everyone is still an administrator.** - Reduces to two administrators - Removes delete permission from 26 people - Explains why at the team meeting → Accidental deletions disappear without anyone experiencing it as distrust. **What worked with five people breaks with fifty.** - Reviews permissions and structure as it grows → The organisation keeps up with the team. **Everyone is still an administrator.** - Adjusts roles to the job → Access stops being general. **Nobody knows who handles what.** - Assigns owners per process → Requests reach somebody. **Each department builds its own templates.** - Unifies what repeats → Improvements reach everyone. **Onboarding new people is done by hand every time.** - Defines an onboarding process → Growth does not consume a person. --- --- id: KB-AD-011 url: https://app.codecontract.io/help/administration/giving-access-to-someone-outside idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-006, KB-IC-010] citadoPor: [KB-AD-014, KB-ET-016, KB-AD-017] --- # Giving access to someone outside _Your accountant, an auditor or a client who wants to look: scoped access with an end date._ **Responde a:** give my accountant access · access for an external auditor · sharing with someone outside the team · invite an outsider without giving everything Sooner or later someone outside needs in: the accountant, an auditor, the client who wants to see their file, the lawyer handling a matter. The temptation is to email the files or hand out an ordinary account. Both end badly. ## The three ways, and when to use each | Way | When | What it leaves | | --- | --- | --- | | Sending the files | A one-off, small delivery | Nothing: outside here there is no control and no record | | Scoped, time-limited access | Accountant, auditor, collaborator | A record of what they saw and when, plus an expiry | | The recipient portal | A client or supplier who only sees their own | They see their part without entering the organisation | > [!IMPORTANT] > The third is the most overlooked. A supplier or client does not need an account in your organisation to see and sign their own: they reach their document by their link and see nothing else, with nothing for you to administer. ## If real access is needed 1. **Their own account, never a shared one** — If three people at the firm log in with the same credentials, the record stops meaning anything. 2. **The lowest permission that works** — Almost always read-only. Start there and widen if needed. 3. **Scoped to their remit** — A quality auditor has no business seeing payroll or invoicing. 4. **And a review date in the calendar** — External access lingers for years. Set the reminder yourselves. > [!WARNING] > The real risk is not that they do something improper: it is that access stays alive after the relationship ended. Review the outsider list twice a year; there is almost always someone left over. ## When it ends **En corto** - Access is withdrawn the day the engagement ends, not when someone remembers. - The record of what they saw remains, and is not erased by withdrawal. - And if they return next year, grant it again: cheaper than leaving it open. > [!NOTE] > Everything an outsider does lands in the activity log exactly like anyone on the team. That is the main difference from emailing files: you can answer "who saw this?" a year later. **Do they count as a team member?** They take a seat like any user; what changes is what they see, not how they log in. **Can they download?** Depending on the permission you grant. Assume anything visible can be copied. **Is it right for a client following their case?** The portal is usually enough there, with no account at all. ## Ejemplos **A company emails its invoices to the accountancy firm every month.** - Grants scoped read access to invoicing with an annual review - Withdraws it when changing firms → Documents stop circulating by email and there is a record of what was consulted and when. **Full access is granted to an occasional external party.** - Grants access only to what they need → They see theirs and nothing more. **The external party finishes and their access stays active.** - Revokes access on completion → Access reflects who is collaborating today. **Somebody who only provides one paper is invited as a user.** - Sends them a link → No licence is consumed. **Nobody knows which external parties have access.** - Checks the list of external access → The picture exists without asking. **The external party asks for more access than planned.** - Extends only what is justified → The scope stays matched to the work. --- --- id: KB-AD-012 url: https://app.codecontract.io/help/administration/i-lost-my-phone-with-the-session-open idioma: en categoria: administracion audiencia: administrador nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-007, KB-AD-001] citadoPor: [KB-AD-013, KB-AD-018] --- # I lost my phone with the session open _What to do in the first ten minutes, and in what order._ **Responde a:** lost my phone with my account logged in · work laptop stolen · log out of a lost device · what to do if i lose my work phone A lost phone or laptop with an open session is not a catastrophe if you act fast, and very much is if it waits until Monday. These are the steps, in the order that matters. ## The first ten minutes 1. **Close that device's session** — From somewhere else. First, because it cuts access instantly. 2. **Change the password** — If the device had it saved, closing the session is not enough. 3. **Check the second factor** — If the lost phone **was** the second factor, replace it before anything else. 4. **And tell an administrator** — Even if it is your own phone: some decisions are not yours to take. > [!IMPORTANT] > The third step trips many people up. If the lost phone was also the one receiving codes, changing the password without solving that can lock you out of your own account. That is why it is checked before touching anything else. ## Afterwards, calmly | What | What for | | --- | --- | | Review the last few hours of activity | To know whether anyone got in, and to what | | Check the device list | Remove any you no longer use | | Check the associated email account | It is the back door to almost everything | | And decide whether anyone else must be told | If third-party data was accessed, there may be an obligation | > [!WARNING] > The last row is not theoretical. If someone accessed documentation containing third-party personal data, assessing whether to notify has short deadlines. That decision is not taken by whoever lost the phone: it is taken by an administrator, which is why the internal alert is step four and not the last. ## What stops it being serious **En corto** - Second factor on something other than the device you lose. - Fingerprint or passcode lock on the phone itself. - Not saving the password in that device's browser. - And reviewing the device list occasionally, not only when something happens. With those four, a lost phone is a problem of replacing a phone, not a security problem. > [!NOTE] > Everything done from that device is in the activity log, with timestamps. That is what lets you answer afterwards what was actually seen, instead of assuming the worst or the best. **Do I lose my work if I close the session?** No: what was uploaded and signed lives in the organisation, not on the phone. **What if it turns up the next day?** You log in as normal. Closing the session breaks nothing. **Must I report it if nothing sensitive was there?** Report it anyway; an administrator decides, and that decision is best recorded. ## Ejemplos **Someone loses their work phone on a Friday afternoon with the session open.** - Closes that device's session from a computer - Checks the second factor did not depend on the lost phone - Tells the administrator → Access is cut within minutes and activity is reviewed calmly on Monday. **A phone is lost with the session open.** - Closes the sessions from another device → Access is cut within minutes. **The second factor was on that phone.** - Recovers access with the administrator → The account comes back without switching security off. **Reporting is delayed out of embarrassment.** - Reports it as soon as it happens → The risk window closes sooner. **Nobody knows what could have been seen from that phone.** - Checks that session's log → The scope becomes known. **The phone is recovered and the matter is considered closed.** - Changes the credentials anyway → The risk does not stay open. --- --- id: KB-AD-013 url: https://app.codecontract.io/help/administration/working-from-a-phone-sensibly idioma: en categoria: administracion audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-001, KB-AD-012] citadoPor: [KB-AD-019] --- # Working from a phone sensibly _What is worth doing from a phone, what is not, and the three precautions that suffice._ **Responde a:** using the platform from a phone · is it safe to work from a phone · access from personal phones · working from a phone on site A good part of the work happens away from a desk: on site, in a warehouse, at a client's, in an airport. Working from a phone is not a concession: for some things it beats a computer, and for others it is clearly worse. ## What is worth doing from a phone | Better on a phone | Better on a computer | | --- | --- | | Uploading a photo of a document | Reviewing a long document | | Signing something brief on the spot | Building or changing a process | | Checking the status of something | Comparing several things at once | | Approving what you already knew | Approving something that must be read in full | > [!IMPORTANT] > The fourth row is the only one worth genuinely respecting. Approving from a phone something you had not read is exactly the failure that is hard to explain afterwards; the rest of the right-hand column is comfort, not risk. ## The three precautions that suffice 1. **Device lock, with fingerprint or passcode** — It prevents 90% of lost-phone problems. 2. **The second factor on something other than the phone** — If it lives on the device you lose, it does not protect what it should. 3. **And not handing over an unlocked phone** — The commonest improper access is not an attack: it is someone looking over a shoulder. > [!WARNING] > Beware saving the password on a shared company phone — the van's, the warehouse's. A device five people use should not hold anyone's open session. ## If you use personal phones **En corto** - Sessions must be closeable remotely, without touching the phone. - Downloads should not linger in the gallery or downloads folder unchecked. - And when someone leaves, access is withdrawn the same day. With that, a personal phone is no riskier than a company laptop. Without it, it is a company archive that leaves with the person. > [!NOTE] > Everything done from a phone is logged exactly as from a computer. And signatures made on a phone are worth exactly the same: the device does not change the value of what is signed. **Do I need to install an app?** No: it works in the phone's browser. **Do photo uploads use much data?** Some. With poor coverage, prepare and upload on the way out. **Can I work offline?** Consulting and acting need a connection; the photo can be taken and uploaded later. ## Ejemplos **A field team uses personal phones and shares one account on the warehouse handset.** - Gives each person their own account and removes the shared session - Moves the second factor off the phone itself → The log says who did what again and a lost phone stops being an incident. **Work happens from a phone on a public network.** - Avoids uploading sensitive documentation from there → Risk drops without stopping work. **The phone is left unlocked on a table.** - Uses screen lock and session timeout → A lapse stops being an access. **Documents are downloaded to the phone and forgotten there.** - Consults rather than downloads → Information is not duplicated outside. **The phone is lent to somebody else.** - Closes the session before handing it over → Access does not travel with the device. **The phone is lost and nobody knows what was on it.** - Checks that session's log → The scope becomes known. --- --- id: KB-AD-014 url: https://app.codecontract.io/help/administration/permissions-nobody-needs idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-010, KB-AD-011, KB-AD-017] citadoPor: [KB-CD-017, KB-AD-020] --- # Permissions nobody needs _Access grows by itself and never shrinks. How to cut it back without breaking anyone's work._ **Responde a:** reviewing user permissions · removing access no longer needed · least privilege in practice · too many people see too much Permissions are granted at a specific moment for a specific reason — a project, an absence, an emergency — and nobody removes them when that reason disappears. Two years on, half the staff can see things they do not need, and nobody remembers why. ## Where surplus permissions come from | Origin | When it was granted | Why it persists | | --- | --- | --- | | A temporary cover | During an absence | Nobody removed it on return | | A project that ended | While it lasted | The project ended, the access did not | | A change of role | On arriving in the new one | It was added to the old rather than replacing it | | "Just in case" | At onboarding | There was never a specific reason | > [!IMPORTANT] > The third row grows fastest and is hardest to see. Someone who has held three roles accumulates all three sets, and on paper they look like a normal user: nobody checks that the sum makes no sense. ## How to review without slowing anyone 1. **Once a year, with a list of who sees what** — An hour catches 90%, and the month does not matter as long as it is always the same. 2. **Start with whoever changed role or department** — That is where the accumulation is. 3. **And with outsiders' access** — The previous accountants, the consultant from the closed project. 4. **Remove and wait** — If someone needed it, they will ask within a week. Faster than auditing case by case. > [!WARNING] > The fourth looks blunt and is the most practical, but with one exception: do not apply it to permissions that automatic processes or integrations depend on. There, remove-and-wait means breaking something nobody is watching. ## What to look at besides who sees what **En corto** - Who can approve, which is different from who can see. - Who can grant permissions to others, the most forgotten of all. - And how many administrators there are: more than three in a small company is too many. The second point decides whether an annual review is sufficient or pointless: if three people can grant access without criteria, the list will grow back by itself within six months. > [!NOTE] > Fewer permissions also means cleaner assistant answers and less noisy searches: each person sees their own, which is almost always what they were looking for. **What if I remove something that was needed?** It is restored in a minute. The cost of a surplus permission lasts years. **Should the review be announced?** Yes, and it cuts complaints to nearly zero. **How often is reasonable?** Annually for everyone; every six months for external access. ## Ejemplos **A company finds an engineer who has held three roles can see almost everything.** - Reviews role-changers first - Removes what no longer applies and waits → Nobody complains and permissions match what each person actually does again. **There are permissions nobody remembers granting.** - Reviews case by case with the owner → What remains has a reason. **Somebody changed role and kept the previous rights.** - Reviews permissions on role changes → Access follows the role. **Broad permissions were granted for a one-off case.** - Withdraws them when the case ends → The temporary stops being permanent. **Nobody has reviewed in years.** - Schedules the periodic review → Access reflects today's organisation. **The review happens and nothing is recorded.** - Records what was reviewed and what changed → The review is demonstrable. --- --- id: KB-AD-015 url: https://app.codecontract.io/help/administration/accounts-shared-between-several-people idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-AD-004] citadoPor: [KB-ET-017] --- # Accounts shared between several people _The reception account, the warehouse one, the admin one: convenient until the day you need to know who did something._ **Responde a:** several people use the same account · shared warehouse account · i cannot tell who made a change · moving away from shared logins Nearly every company has one: an account three or four people use because "it belongs to the desk". It works fine and causes no trouble until the day a very specific question needs answering — who did this, when, and with what permission — and there is no answer. ## What a shared account breaks | What breaks | Practical consequence | | --- | --- | | The activity log | It says what was done, not who: it stops working as evidence | | Offboarding someone | They leave and still know the password | | Alerts and tasks | They go to nobody's inbox and get read by whoever remembers | | The assistant's answers | It sees what the account sees, not what each person should | > [!IMPORTANT] > The second row accumulates the most real risk and is the most invisible. When someone leaves, their own access is withdrawn — but if they knew the shared password, that password stays valid and nobody changes it, because changing it means telling the other three. In practice, that access outlives the person by years. ## How to get out of it without falling out with the team 1. **Count what it is actually used for** — It is nearly always two or three specific tasks, not "everything". 2. **Give each person their own account** — With the permission those tasks need, which is usually less than the shared one has. 3. **Leave no open session on the common device** — The step that meets most resistance and changes the most. 4. **And retire it after a month unused** — Not before: if something depended on it, that month will show it. > [!WARNING] > The common-device case — the warehouse computer, the reception tablet — is what really has to be solved, because that is where shared accounts are born. The answer is not to ban it: it is that each person logs in as themselves and the device stores nobody's password. If that turns out to be too awkward for the pace of work, say so openly and find another route, because a rule that gets in the way gets bypassed. ## When a non-personal account is legitimate **En corto** - For an integration or an automatic process: there is no person behind it, and that is fine. - With minimum permissions and a named owner, even if they never use it. - And knowing what breaks if it is revoked, which is exactly what "remove and wait" cannot test. > [!NOTE] > Everything done from the shared account stays in the log: it is not lost when you stop using it. What cannot be done is reconstructing afterwards which of the four people did what — which is why the change is worth making before you need it, not after. **Does each person take a seat?** Yes, every user counts; in exchange the log says who did what again. **What if the team resists?** It is nearly always about the awkwardness of logging in, not the principle. Solve that first. **Can I find out who used the shared account in the past?** The log shows the account, not the person. That is exactly what is lost. ## Ejemplos **A warehouse works from a common account on the goods-in tablet.** - Gives the four people on shift their own accounts - Leaves no saved password on the tablet and retires the shared one after a month → The log says who received each delivery again — exactly what was missing in the last claim. **One account is used by three people.** - Gives each of them an account → The log says who did what. **Somebody leaves and the shared password has to change.** - Removes only their account → Nobody else has to change anything. **Nobody knows who made a change.** - Checks the log by user → The action has an author. **The shared account is used to save licences.** - Weighs the real cost of not knowing who did what → The decision is taken with both sides in view. **The password is shared over messaging.** - Creates individual accounts instead of sharing → The credential stops circulating. --- --- id: KB-AD-016 url: https://app.codecontract.io/help/administration/who-can-see-your-documents idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-004, KB-NO-014, KB-AD-019] citadoPor: [KB-AD-007] --- # Who can see your documents _The question everyone asks before uploading anything, answered with what can be checked._ **Responde a:** who has access to my documents · can the vendor see my data · support access to our account · where is the data hosted It is the first serious question anyone asks before putting their clients' documentation somewhere new, and it deserves an answer you can check rather than a promise. There are three separate circles, and it helps to look at them one at a time. ## The three circles | Who | What they see | How you check it | | --- | --- | --- | | Your team | Whatever their role and permissions allow | The activity log: it says who opened what and when | | Third parties you invite | Only their own, or what you grant | The same log, with their name | | The platform's providers | What operating the service requires | The public subprocessor list and what you signed | > [!IMPORTANT] > Over the first circle you have full control and proof: **every access is logged, including read-only ones**. That means the answer to "who has seen this document?" does not depend on trusting anyone, not even inside your own company. It is the most underestimated point when evaluating a tool and the most valuable the day there is a suspicion. ## What to ask for in writing before signing 1. **Where the data is hosted** — Country and infrastructure provider, not "in the cloud". 2. **Which subprocessors are involved and for what** — There should be a public, current list, with notice when it changes. 3. **In what cases support accesses, and with what trail** — The right question is not whether they can, but when and what is recorded. 4. **And what happens at the end** — How you take everything with you and what is deleted, with timeframes. > [!WARNING] > Be sceptical of "nobody on our team can see anything". In any service run by people, someone administers the infrastructure, and claiming otherwise is a simplification that collapses in the first serious audit. The credible answer is not that it is impossible: it is **what is restricted, what is logged and what you signed** — that is what an auditor checks and what you can demand. ## What you can do to shrink the circle **En corto** - Grant the minimum permission, and review annually who sees what. - Withdraw outsiders' access when the engagement ends. - Avoid shared accounts, which break the log. - And decide which sensitive documentation goes in and which does not need to. The last is the least technical and the most effective: not everything that exists in your company has to live in any tool. > [!NOTE] > If a client sends you a security questionnaire, these are the same questions they will put to you — and a public subprocessor list is part of an answer you can give without negotiating anything. **Can I find out whether someone viewed a specific document?** Yes, in the activity log, with name and time. **Does the assistant see more than I do?** No: it answers with what your permissions allow you to see. **What if I need a formal answer for a client?** Ask for it in writing and keep it with that client's documentation. ## Ejemplos **An advisory firm hesitates to upload its clients' documentation to a new tool.** - Asks in writing about hosting, subprocessors and the support access trail - Checks that the activity log also records views → Signs with an answer it can show its own clients when they ask. **A client asks who can see their documents.** - Checks that file's permissions → The answer is specific. **The whole team sees every client's documentation.** - Limits access according to the engagement → Sensitive material stays where it should. **It is shared with an external party who sees more than intended.** - Checks the scope before sharing → They see theirs and nothing more. **Nobody knows who has opened a document.** - Checks the access log → The question has an answer. **The client is answered from memory.** - Checks before answering → What is asserted is true. --- --- id: KB-AD-017 url: https://app.codecontract.io/help/administration/when-the-team-is-in-several-countries idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-011, KB-CC-016, KB-AD-010] citadoPor: [KB-AD-014] --- # When the team is in several countries _Four things that stop working by themselves once people share neither time zone, language nor calendar._ **Responde a:** team across several countries · users in different time zones · working with offices abroad · alert language per user Everything that works without thinking when a team shares an office starts failing subtly when it does not: alerts land at odd hours, deadlines get read differently, and requests go out in a language the recipient half understands. ## The four to watch | What | What happens if ignored | What to do | | --- | --- | --- | | The timing of alerts | They go out overnight and get ignored | Schedule to the recipient's working day | | Language | The request is half understood and half answered | Write to each third party in theirs | | Public holidays | A deadline falls on a day nobody works there | Count with margin, not with your own calendar | | Where the data is | It surfaces in the first client questionnaire | Know it and be able to answer in writing | > [!IMPORTANT] > The third breaks the most deadlines and is anticipated by nobody. A notice due on the 15th in your calendar may fall on a local holiday in the recipient's country, and a campaign launched during a holiday week there gets half the response with nothing having gone wrong. With distributed teams, margin stops being prudence and becomes a requirement. ## What to decide up front 1. **Which language each third party is written in** — The recipient's, not head office's. It lifts response more than anything else. 2. **Who answers in each time band** — If a client writes at seven their morning, the responder cannot be someone starting six hours later. 3. **What is centralised and what is decided locally** — Above all what documentation is required: if each country asks for its own without criteria, no system will tidy it. 4. **And how deadlines are counted** — Calendar or working days, and against which calendar. Written down, not assumed. > [!WARNING] > The point discovered late: **the question of where data is hosted stops being theoretical the moment you have clients or employees in another country**. It is not just a questionnaire box — it can affect what you can promise contractually. Knowing the answer and having it in writing before being asked is the difference between replying in a minute and stalling a negotiation. ## What does not change **En corto** - The file is the same for everyone, wherever they are. - The activity log records the time, so "when was this done" arguments resolve the same way. - And third parties still enter by their link, with no account and in their own language. That last is what makes working with suppliers across countries viable without building a structure per country: whoever supplies does not need to understand your organisation, only what you are asking for. > [!NOTE] > Obligations about where data is processed and what may be transferred depend on the country and the type of data, and they change. **Confirm that with your adviser**; this only flags that it is a question that will arrive and is worth having an answer ready for. **Can each user have the interface in their language?** Yes, and it helps: it cuts interpretation errors in daily work. **What if the team in another country wants its own organisation?** It depends on whether someone must stop seeing the other's material; if not, you complicate administration for nothing. **Do reminders respect the recipient's time zone?** If scheduled, yes; launched unscheduled, they inherit the send time. ## Ejemplos **A company with an office abroad launches its annual campaign without checking their calendar.** - Schedules sends to local working hours and counts deadlines with margin → That office's response stops running two weeks behind everyone else's. **The team is spread across countries and notices arrive at night.** - Schedules by each person's local time → The notice arrives within their working day. **Each country keeps its documentation separately.** - Centralises with permissions per team → The overall picture exists without mixing. **Notice languages do not match the recipient.** - Records each person's language → The notice goes out in the right language. **A local public holiday goes unnoticed.** - Accounts for each country's calendar → Deadlines are set sensibly. **The same permission criteria apply everywhere.** - Adjusts to what each team needs → Access matches the real work. --- --- id: KB-AD-018 url: https://app.codecontract.io/help/administration/losing-your-second-factor idioma: en categoria: administracion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-012, KB-AD-002] citadoPor: [KB-AD-001] --- # Losing your second factor _A new phone, a wiped phone, a deleted app. A minute's work if you kept what needed keeping._ **Responde a:** changed phone and cannot log in · lost my verification codes · what are recovery codes for · regain access without my phone A second factor protects the account from someone getting in with a stolen password. It works so well that it also locks you out the day the phone is replaced, wiped or lost — and that day is rarely a calm one. ## The three cases, and what differs between them | What happened | Is there still an open session | Way out | | --- | --- | --- | | New phone, old one to hand | Usually yes | Set the second factor up again from settings, calmly | | Phone wiped or app deleted | Sometimes | The recovery codes, if they were kept | | Phone lost or stolen | Possibly, and that is the urgent part | Close sessions and change the password first | > [!IMPORTANT] > The part that catches everyone out: **recovery codes are single use**. They are not an alternative password that always works — each one you use is spent and stops working, and they come as a handful, not an endless list. They are also shown **only once**, when the second factor is switched on. Whoever did not copy them then does not have them, and there is nowhere to look them up again. ## Where the codes should live **En corto** - In the password manager, if the team uses one: that is their natural home. - Or printed, with the company's important papers. - Never on the same phone that acts as the second factor: lose it and you lose both. - And not in an email to yourself: whoever gets into the mailbox gets into the account. > [!WARNING] > What almost nobody plans for: **the second factor is managed from each person's own settings, not from the admin ones**. A colleague, however senior an administrator, does not switch yours back on with a click. With no codes and no open session, getting back in goes through support and through proving who you really are — and that takes time, on exactly the day something had to be signed. ## The five minutes that save the bad day 1. **Switch the second factor on and copy the codes there and then** — Not «later»: the screen does not come back. 2. **Keep them somewhere that is not the phone** — Password manager or paper. 3. **Add the second factor in two places if you can** — Many apps also allow it on a tablet or computer. 4. **And when changing phone, migrate it before wiping the old one** — The most repeated mistake, and the most avoidable. > [!NOTE] > If you suspect the loss was not accidental, the order changes: close sessions and change the password first, then recover access at your own pace. **Can I turn the second factor off «in the meantime»?** Only from inside. And if you can get in, better to fix it than switch it off. **Can new codes be generated?** Yes, from settings, and it is worth it when few are left: the old ones stop working. **What if the whole company shares one phone?** That is a different and bigger problem: one each. ## Ejemplos **Someone changes phone and wipes the old one before migrating the second-factor app.** - Uses one of the codes kept in the password manager and sets it up again → Access is back in a minute at the cost of one code, instead of raising a support case. **The second factor is lost and nobody can sign in.** - Recovers access with the administrator → The account comes back without switching security off. **The only administrator is the one who lost it.** - Keeps two administrators active → Somebody can always recover. **The second factor is switched off to get past it.** - Restores it on the new device → Security does not stay off. **It is lost along with the phone and an open session.** - Closes the sessions as well as recovering → The previous access is cut. **It happens often and is always fixed by hand.** - Documents the procedure → Recovery stops depending on whoever knows. --- --- id: KB-AD-019 url: https://app.codecontract.io/help/administration/which-security-alerts-are-worth-switching-on idioma: en categoria: administracion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-004, KB-AD-007, KB-AD-013] citadoPor: [KB-AD-016] --- # Which security alerts are worth switching on _An alert that reaches everyone reaches nobody. Which ones matter and who they must reach._ **Responde a:** account security alerts · new device login notifications · who should receive the alerts · too many security notifications Many things can be alerted on, and that is the problem. When everything alerts, the team learns to ignore it within two weeks, and the alert that mattered arrives on the same day as thirty others. The question is not what can be alerted: it is what deserves to interrupt someone. ## The ones worth an alert | Event | Why it matters | Who it must reach | | --- | --- | --- | | Someone signs in from a new device or place | First sign of a compromised account | That person, always | | A password or second factor changes | If it was not you, it is urgent | That person, immediately | | Someone gains administrator rights | It changes what that account can do to everything | The administrators | | An integration key is created or withdrawn | It opens or closes a door that is not a person | The administrators | | Many failed attempts in a row | Someone is trying | The administrators | > [!IMPORTANT] > And the criterion that decides whether this works is not on the list, it is the recipient: **a security alert cannot go only to a shared mailbox everyone can read**. If the compromised account is one of those reading that mailbox, whoever got in sees the alert before you do and can delete it. A person's alerts go to that person; the organisation's go to two named administrators, not to `info@`. ## What is better left unalerted **En corto** - Every normal sign-in: it is noise, and it buries everything else. - Every document someone opens: that is what the log is for, consulted when needed. - And anything nobody will look at twice in a row. > [!WARNING] > There is a consequence of this that surprises people: **the best alert is the one that almost never arrives**. If your team gets a security alert every couple of weeks, the day a real one lands they will read it carefully. If they get five a week, that day they will file it with the rest. Tuning what alerts is not about comfort: it decides whether the alert works when it counts. ## How to set it up in ten minutes 1. **Switch on the five in the table and nothing else at first** — Widen it later if something is missed. 2. **Name the people who receive the organisation ones** — Two people, not a mailbox; and both should know they get them. 3. **Check they actually arrive, once** — Sign in from another device and see whether it warns you. 4. **And decide what happens on receiving each one** — An alert with no action attached ends up ignored. > [!NOTE] > If an alert nobody recognises ever arrives, the order matters: close sessions and change that account's password first, investigate afterwards. It is set out step by step in the article on suspected access. **What if the team travels a lot?** The new-device alert will keep firing: that is correct, and it is dismissed in a second. **Do alerts replace reviewing the log?** No: they flag the urgent. The monthly review catches what does not fire. **Should management be alerted?** Only about what they will decide. Otherwise it is noise with more seniority. ## Ejemplos **A company sends every security alert to the general admin mailbox.** - Routes personal alerts to each person and organisation ones to two named administrators → The alert reaches someone who can act, not a mailbox anyone can clear. **No security notices are switched on.** - Turns on those warning about access and changes → The odd thing shows in the moment. **Notices go to a single person.** - Addresses them to more than one → The notice reaches somebody who can act. **There are so many notices nobody reads them.** - Leaves on the ones that genuinely matter → The notice works again. **A notice fires and nobody knows what to do.** - Writes down what to do with each → The response is not improvised. **Notices go to a mailbox nobody watches.** - Directs them to a monitored address → The notice gets read. --- --- id: KB-AD-020 url: https://app.codecontract.io/help/administration/who-should-be-able-to-delete idioma: en categoria: administracion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-014, KB-DI-010, KB-AD-009] citadoPor: [KB-AD-003] --- # Who should be able to delete _The permission handed out most thoughtlessly, and the only one whose mistake shows up when you need what is gone._ **Responde a:** who can delete documents · someone deleted something by mistake · delete permissions for the team · can deleted items be recovered When permissions are set up, deleting usually rides along with editing: if someone can work on a file, they can remove things from it. That seems reasonable until someone tidies away what they think is surplus and it turns out to be the only copy of something needed three months later. ## What is worth separating | Action | Who should be able to | Why | | --- | --- | --- | | Upload and correct | Most of the team | It is the daily work | | Archive or take out of view | Whoever works with it | Tidies without destroying | | Actually delete | Very few people | It is the only irreversible one | | Delete at a third party's request | Whoever holds that responsibility | It has consequences outside the company | > [!IMPORTANT] > The distinction between the two middle rows prevents nearly every scare: **getting something out of the way and destroying it are not the same need**. When someone says «this is surplus», they almost always mean it clutters their list, not that it should be destroyed. If those two actions are one, a tidying gesture takes out a piece of evidence — and whoever did it was right that it cluttered and had no intention of breaking anything. ## What remains when something is deleted **En corto** - The log says who deleted it and when, even with the document gone. - That lets you reconstruct what was missing and from when, which is not nothing. - But it does not return the content: a trace is not a substitute. - And if it was sealed, what is lost is the copy, not the record that it existed. > [!WARNING] > The case worth settling before it happens: **deleting at a person's request about their own data is not the same as deleting because something clutters**, and it often arrives from outside with a deadline. If that ability is spread across the whole team, anyone can handle such a request badly — deleting too much, or deleting something you were required to keep for another reason. Exactly the kind of decision settled once with your adviser and left with one or two people. ## How to set it up 1. **Give almost everyone archive, and almost nobody delete** — It covers 95% of the times someone wants «this gone». 2. **Name who a real deletion is requested from** — Having to ask makes people think twice. 3. **Review who holds it once a year** — This permission is inherited on role changes and never withdrawn. 4. **And look at the deletion log now and then** — Ten minutes that teach a lot about how things are being used. > [!NOTE] > What you must keep and for how long, and how that squares with a personal-data deletion request, depends on your activity and the framework that applies. **Your adviser settles that**; here it is about that deletion not being executable by anyone by accident. **Can something deleted be recovered?** It depends how and when: ask soon, not in a month. **What if something is deleted before we review it?** The log says who and when; the content, absent a copy, does not come back. **Should deletions raise an alert?** Yes, to administrators: one of the few alerts worth having. ## Ejemplos **Someone tidies a file and deletes the only copy of a certificate that cluttered the list.** - Gives the whole team archive and reserves deletion for two people → Tidying can no longer destroy anything, and the clutter still gets cleared. **Anyone can delete a document.** - Limits deletion to the right people → Deletion stops being accidental. **Something is deleted and nobody knows who did it.** - Checks the action's log → The deletion has an author and a date. **Something that had to be kept is deleted.** - Checks the policy before deleting → Deleting stops being a gamble. **Deletion rights are requested to clean up duplicates.** - Grants the permission to whoever reviews → The clean-up happens on a basis. **An external party has deletion rights for no reason.** - Reviews what they actually need → The permission matches the work. --- --- id: KB-AD-001 url: https://app.codecontract.io/help/administration/account-security idioma: en categoria: administracion audiencia: administrador actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-002, KB-TZ-001, KB-ET-001, KB-AD-005, KB-AD-018] citadoPor: [KB-CD-002, KB-AD-012, KB-AD-013, KB-AD-002] enLaApp: https://app.codecontract.io/settings/security --- # Securing your organisation's account _Second factor, devices, single sign-on and what to check when something feels off._ **Responde a:** enable two-factor authentication · securing my organisation's account · set up single sign-on SSO · sign out of a lost device · company password policy In an account holding signed contracts and evidence with probative value, security is not an optional setting you look at in year two. Three things are worth settling in the first month, and one is worth knowing how to check when a doubt arises. **En corto** - Two-factor is mandatory for administrators and advisable for everyone. - Passkeys are both more convenient and more secure than a password. - Single sign-on centralises joiners and leavers in the system you already use. - The audit log is what answers "who logged in and what did they do". ## Two-factor authentication It is the measure that removes the most risk for the least effort. A password leaked somewhere else stops being enough to get in. For accounts with administration rights it is not negotiable: those are the ones that can change the whole organisation's configuration. ## Passkeys They replace the password with the device's fingerprint or face. There is nothing to remember and nothing to leak, and they cannot be phished with a fake email because they are bound to the real domain. If your team uses modern phones or laptops, it is the most convenient and the most secure route at once. ## Single sign-on If your company already runs a corporate identity system, connecting the platform to it avoids the classic problem: someone leaves, their email is removed and this account is forgotten. With single sign-on, there is only one offboarding to do. > [!WARNING] > Before enabling single sign-on, make sure at least one administrator keeps direct access. If the connection fails and nobody can get in another way, recovering access is a great deal slower. ## When something feels off 1. **Check the devices with an open session** — One you do not recognise can be signed out from there, changing nothing else. 2. **Review the audit log** — Who logged in, from where and what changed. That is what turns a suspicion into a fact. 3. **Change the password and enable two-factor** — In that order: changing it without a second factor leaves the door just as open. ## Frequently asked questions **Can I require two-factor for the whole team?** Yes, it can be enforced by organisation policy. For administration accounts it should always be mandatory. **What if someone loses the phone with their second factor?** An administrator can reset it for them. Which is why it matters that more than one person holds that permission. **Does an external participant need two-factor?** They have no account, so it does not apply. Their access is a personal link, and on advanced signatures they are verified with the SMS code. **Can I enforce a minimum password length?** Yes, there is a password policy configurable per organisation. ## Ejemplos **An administrator gets a sign-in alert from a country where they have nobody.** - Opens the device list and signs out the session she does not recognise - Reviews the log for what that session did - Requires two-factor on every account with administration rights → She knows exactly what was touched and closes the door the same day, instead of wondering for a week. **There is one administrator and they are on holiday.** - Names two administrators from the start → The account does not depend on one person. **Nobody has reviewed who has access in years.** - Schedules a periodic review → Access reflects today's organisation. **The second factor is switched off.** - Turns it on with advance notice → The account is protected without blocking anyone. **A security notice arrives and nobody reads it.** - Addresses notices to more than one person → The notice reaches somebody who can act. **An account is shared between several people.** - Gives each one their own account → The log says who did what. --- --- id: KB-AD-002 url: https://app.codecontract.io/help/administration/protecting-your-team-accounts idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-001, KB-AD-003] citadoPor: [KB-AD-004, KB-PR-004, KB-ET-008, KB-AD-005, KB-AD-006, KB-AD-007, KB-AD-008, KB-AD-009, KB-AD-010, KB-AD-015, KB-AD-018, KB-ET-011, KB-AD-003, KB-ET-005, KB-IN-003] enLaApp: https://app.codecontract.io/settings/security --- # Protecting your team's accounts _The three measures that prevent nearly everything, ordered by effort._ **Responde a:** enable two-factor authentication · require 2fa for the whole team · how do i protect my company account · someone accessed an account What sits inside are contracts, payroll and identity documents belonging to people who are not here to protect them. Three measures cover almost everything that can go wrong, and all three take one afternoon. ## 1. Two-factor, mandatory A password on its own leaks: it gets reused, written down, stolen from another service. A second factor means a stolen password is not enough. By some distance it is the best protection per unit of effort. > [!IMPORTANT] > Make it mandatory for the whole organisation, not optional. Optional means three people turn it on and the other twenty do not. ## 2. Each person with their own Making everyone an administrator is convenient until the day someone deletes something. Those who only look, look; those who only sign, sign. ## 3. Watch who signs in The log shows who signed in, from where and what they did. Reviewing it monthly catches the account of someone who left six months ago and is still open. | Measure | Effort | Prevents | | --- | --- | --- | | Mandatory two-factor | One afternoon | A leaked password opening the door | | Tight permissions | Half an hour | Accidental deletions and changes | | Monthly review | Ten minutes a month | Live accounts for people who left | > [!WARNING] > When someone leaves, remove their access that same day. It is not distrust: it is that their account stays open and nobody is watching it any more. **What if someone loses their two-factor phone?** An administrator restores access after checking who they are. Which is why you want two administrators. **Can people sign in with their work account?** Yes, if you have corporate sign-in. It is the easiest option once you are many. **Am I warned about odd sign-ins?** Sign-ins are logged with their location and device. ## Ejemplos **A sixty-person company makes two-factor mandatory.** - Warns everyone a week ahead - Switches it on a Monday - Keeps two administrators able to restore access → Four people need help on day one and none after that. **Somebody uses the same password as elsewhere.** - Turns on the second factor for everyone → A leaked password stops being enough. **The second factor is switched on unannounced and everyone locks out.** - Gives a week's notice and leaves a recovery route → The change happens without stopping work. **Nobody knows who has the second factor active.** - Checks the status per person → The gaps become visible. **Somebody loses a phone with the session open.** - Closes their sessions from administration → Access is cut within minutes. **An account is shared to get past a problem.** - Creates that person their own account → The log keeps saying who did what. --- --- id: KB-AD-003 url: https://app.codecontract.io/help/administration/removing-someone-from-the-team idioma: en categoria: administracion audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-ET-002, KB-AD-020] citadoPor: [KB-TZ-003, KB-ET-010, KB-ET-013, KB-AD-002, KB-ET-007, KB-CF-007] enLaApp: https://app.codecontract.io/settings/members --- # Removing someone _What happens to their work, their pending signatures and their documents._ **Responde a:** delete a user from the team · an employee is leaving what about their account · transfer someone's cases · revoke a colleague's access Someone is leaving. The urgent thing is to cut their access; the important thing is that their work is not orphaned. They are two different jobs and both are worth doing. 1. **Remove access today** — The same day, not at month end. Their open account is no longer watched by anyone. 2. **Hand over what they were carrying** — Their open cases and pending sends move to someone else. Otherwise they sit waiting for a person who is not coming back. 3. **Leave their trail alone** — What they did stays signed by them, with their name and date. It is not rewritten. ## What goes and what stays | Item | What happens | | --- | --- | | Documents they uploaded | Stay. They belong to the organisation, not to them | | Cases they owned | Transferred to whoever you say | | What they signed | Stays signed by them, permanently | | Their personal account data | Deleted on request, without erasing the record | > [!NOTE] > Signatures staying in their name is not an oversight: a signature that changed owner when someone left would prove nothing. > [!WARNING] > If that person was the only administrator, appoint another before removing them. Otherwise the organisation is left with nobody able to change anything. **Can I restore the account if they come back?** You invite them again. A new account with their history intact. **What about half-finished signature requests?** They are reassigned to the new owner without redoing the whole circuit. **Are the third parties they dealt with notified?** Not automatically. If they held a live relationship, it is worth saying so. ## Ejemplos **The purchasing manager leaves with eleven supplier onboardings open.** - Access is removed on their last day - The eleven cases move to their replacement - Their earlier signatures stay in their name → No supplier is left waiting on an address nobody reads any more. **Somebody leaves and their access stays active.** - Revokes access on their last day → The account reflects who works here. **Their account is deleted and their actions vanish.** - Deactivates rather than deletes → The history stays true. **Their files stay in their name.** - Reassigns them before the departure → No third party is left waiting. **Notices keep going to their address.** - Changes the recipient on the files → Notices reach somebody who exists. **Closing their open sessions is forgotten.** - Closes the sessions on deactivation → Access is genuinely cut. --- --- id: KB-CD-003 url: https://app.codecontract.io/help/credits-and-billing/keeping-credit-spend-under-control idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-001, KB-CD-002, KB-CD-017, KB-CD-019] citadoPor: [KB-CD-007, KB-CD-008, KB-CD-010, KB-CD-013, KB-CD-018, KB-CD-004, KB-CD-006] enLaApp: https://app.codecontract.io/credits --- # Keeping spend under control _Know where it goes, cap it, and avoid running dry mid-send._ **Responde a:** see what credits are spent on · cap a team's spend · alert when credits run low · monthly consumption report Spend usually goes out of control for one reason: someone launches a large batch without looking, or SMS is used by default where email would have done. Both show up in the breakdown. ## Where it goes in practice | Item | Typical weight | How to reduce it | | --- | --- | --- | | Signature sends | The bulk | Little to do: it is the work itself | | SMS and WhatsApp | The one that surprises people | Use only for people who do not read email | | Document reading | Steady | Turn it off for types that yield no useful data | ## Three measures that avoid surprises 1. **Low-balance alert** — Set so it arrives with room to top up, not once it is gone. 2. **Check the breakdown monthly** — Ten minutes. It is where you spot SMS left on by default in a three-hundred-person process. 3. **Do the sum before a large batch** — Four hundred sends are four hundred. Checking the balance first avoids stopping halfway. > [!WARNING] > Running out mid-batch breaks nothing, but it splits the work in two and forces you to reselect whatever was left. > [!NOTE] > Before cutting, check whether the spend is saving you something. A signature send costs less than the time to print, courier and file the paper. **Can I see spend per team?** Yes, in the breakdown. **Can I cap an individual?** It is controlled by permissions: someone who cannot launch large batches cannot spend in bulk. **Am I warned before an expensive batch?** The total is shown before you confirm. ## Ejemplos **Spend spikes one month for no obvious reason.** - Looks at the breakdown - Finds a 300-participant process had SMS on by default - Restricts it to people without email → The following month returns to normal without anyone missing their notices. **Spend is discovered at month end.** - Checks consumption during the month → The correction arrives in time. **An automated process consumes more than expected.** - Reviews which activities it generates → Spend that runs on its own gets controlled. **Nobody knows which department consumes what.** - Checks consumption by department → The conversation happens with data. **You want to set a limit and do not know where.** - Estimates from previous months' consumption → The limit is set on a basis. **The balance runs out mid-campaign.** - Warns before reaching the threshold → The campaign is not interrupted. --- --- id: KB-CD-002 url: https://app.codecontract.io/help/credits-and-billing/what-uses-credits-and-what-does-not idioma: en categoria: creditos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-001, KB-AD-001, KB-CD-020] citadoPor: [KB-CD-003, KB-PR-006, KB-CD-015, KB-CD-021, KB-CD-004, KB-CD-005, KB-CD-006] --- # What uses credits and what does not _The list of what consumes, so you can work it out before starting._ **Responde a:** how many credits does a signature use · what consumes credits · how much does sending a document cost · i am running out of credits Almost any action the platform performs for you consumes a credit: sending a notice, creating a process, uploading a document, reading with AI, sealing. What does not consume is looking at what is already inside. | Action | Uses credits? | | --- | --- | | Sending a document for signature | Yes | | Sending a notice: email, SMS or WhatsApp | Yes, one per request even if it goes to several | | Creating or duplicating a process | Yes | | Uploading a document | Yes | | Reading a document with AI | Yes | | Certifying evidence or sealing | Yes | | Generating a report | Yes (downloading it, no) | | Viewing, filtering and downloading what is already inside | No | | A third party signing or delivering | No, never costs them anything | > [!NOTE] > Cost follows the action, not the recipient: a bulk send to two hundred people consumes the same as to one. That is what makes large batches worthwhile. ## Before a large send If you are about to send four hundred amendments, check the balance first. Running out mid-way breaks nothing — what went out went out — but it means redoing the selection. **Do they expire?** Not with time. But they cannot be spent if the licence lapses, so in practice they depend on keeping it current. **Can they be shared between teams?** The balance belongs to the organisation; teams draw from the same pool. **What happens if they run out halfway?** What already went out continues. The rest waits for balance. ## Ejemplos **A company works out the cost of sending the annual amendment to 320 employees.** - Counts 320 signature sends - Adds SMS only for the 40 without a work email → They know the cost before starting, instead of discovering it halfway. **A feature is avoided for fear it consumes.** - Checks what consumes before deciding → The decision uses the fact rather than the suspicion. **An action is repeated in case it was not done.** - Checks first whether it already happened → You stop paying twice for the same thing. **Nobody knows whether consulting consumes.** - Checks the list of what consumes → The team works without holding back. **The year is planned counting activities that do not consume.** - Adjusts the forecast to what does consume → The estimate moves closer to reality. **A process change drives consumption up unintentionally.** - Reviews which activities the new process adds → The cost is visible before rollout. --- --- id: KB-CD-007 url: https://app.codecontract.io/help/credits-and-billing/the-invoice-does-not-add-up idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-003, KB-CD-004, KB-CD-014] citadoPor: [KB-CD-013] enLaApp: https://app.codecontract.io/credits --- # The invoice does not add up _Where to look to explain a month that came out unusual._ **Responde a:** why did i use more credits this month · review this month's usage · unexpected spend on the platform · reconcile usage with the invoice A month spikes and nobody remembers doing anything different. There is nearly always a concrete explanation, and it is in the breakdown: spend is not spread evenly, it concentrates in two or three things. ## The four causes, by frequency | Cause | How to spot it | What to do | | --- | --- | --- | | A large batch someone launched | A spike on a single day | Check who and why; it is usually legitimate | | SMS left on by default in a process | Steady, spread-out spend | Restrict SMS to people who do not read email | | Reading enabled on a type that yields nothing | Rises with upload volume | Disable reading for that type | | Resends of a badly filtered batch | Duplicates on the same day | Filter for who did not receive before relaunching | ## How to review it in ten minutes 1. **Open the month's breakdown and sort by item, not by date.** 2. **Check whether one process accounts for more than half.** 3. **Compare with last month: what changed is what needs explaining.** > [!NOTE] > Before cutting, check whether the spend is returning something. An expensive month because the annual review of 300 suppliers went out is not a problem: it is the annual review, and last year it was done by hand. > [!WARNING] > Be careful cutting SMS wholesale to save money. If those were the ones reaching people who do not read email, next month you will spend less and receive less, which costs more. > [!IMPORTANT] > If the spike is explained by none of this, check it against the activity log before assuming a billing error. Consumption nobody recognises deserves a look at who launched it. **Can I see spend per person?** It is shown per process and per team, which is usually what explains it. **Can the breakdown be exported?** Yes, with its dates. **Are reminders charged separately?** No. Chasing an already-paid send is not charged again. ## Ejemplos **Usage triples in March for no obvious reason.** - Sorts the breakdown by item - Finds a 300-person process had SMS on by default → Restricts it to the 40 without a work email and April returns to normal without losing deliveries. **The invoice does not match expectations.** - Compares it with the period's consumption breakdown → The difference is located in minutes. **Consumption appears from a department that did not expect it.** - Checks the breakdown by department and activity → The origin is identified. **There is a spike nobody remembers.** - Checks what happened on those days → The spike has an explanation. **A dispute is raised without specific data.** - Provides the breakdown of the activities in question → The dispute is resolved precisely. **Reconciling takes the same effort every month.** - Reviews consumption during the month → The close stops holding surprises. --- --- id: KB-CD-008 url: https://app.codecontract.io/help/credits-and-billing/buying-more-credits idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-005, KB-CD-003] citadoPor: [KB-CD-017] --- # Buying more credits _How to top up, how much is sensible, and what to check first._ **Responde a:** how do i buy more credits · top up balance · how many credits do i need · who can buy credits Topping up is immediate and done by whoever holds that permission. The only thing worth a minute's thought is how much, because running short mid-batch splits the work in two. ## How much to buy | If your usage is... | Buy | | --- | --- | | Steady month to month | Two or three months' worth, and set the low-balance alert | | Seasonal, with clear peaks | Before the peak, sized to the batch | | Not known yet | A little, and look at the breakdown after the first month | ## Before a large batch **En corto** - Count the sends: four hundred amendments are four hundred. - Add the SMS separately if you will use them. - Check the balance before launching, not halfway. > [!NOTE] > Credits do not expire with time. What does make them unusable is the licence lapsing, so buying many months' worth only makes sense if the licence covers that period. > [!WARNING] > Running out mid-batch breaks nothing — what went out continues — but you have to relaunch filtered to whoever did not receive, and that is avoidable work. **Who can buy?** Whoever holds that permission; usually an administrator. **Is it available immediately?** Yes, topping up is instant. **Can top-ups be automated?** Ask about it if your usage is high and steady. ## Ejemplos **A company is about to send the annual amendment to 340 staff and is unsure about balance.** - Counts 340 sends plus SMS for the 40 without email - Tops up before launching → The batch goes out whole on the same day, without splitting. **Balance is bought once it has already run out.** - Warns before reaching the threshold → The purchase happens without interrupting work. **Too little is bought and it has to be repeated monthly.** - Estimates from previous months' consumption → The purchase is sized for the period. **Too much is bought and it is left over at year end.** - Adjusts to the real forecast → The balance gets used. **Nobody knows who can buy.** - Defines who authorises the purchase → Topping up does not depend on one person. **A big campaign arrives and the balance falls short.** - Estimates the peak separately and buys beforehand → The campaign starts unhindered. --- --- id: KB-CD-009 url: https://app.codecontract.io/help/credits-and-billing/why-was-i-charged-for-this idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-005, KB-CD-004] citadoPor: [KB-CD-010, KB-CD-013, KB-CD-019, KB-CD-021] --- # Why was I charged for this? _The five charges that surprise people, and why they exist._ **Responde a:** why am i charged when creating a process · i do not understand a credit charge · charged for uploading a document · consumption i do not recognise The surprise nearly always comes from assuming only outbound things are charged. They are not: what is charged is the action the platform performs, whether it leaves or not. These are the five that surprise most. | Charge | Why it exists | | --- | --- | | Creating or duplicating a process | Building the circuit is system work, not just sending it | | Uploading a document | It is stored encrypted, indexed and made searchable by content | | Sending an email | It leaves our sending infrastructure, exactly like an SMS | | Generating a report | It is computed when generated; downloading it later is not charged again | | Each webhook delivery | It is a call to your system, one per event | ## What is NOT charged though people think it is **En corto** - Viewing, filtering and downloading what is already inside. - A third party opening their link, delivering or signing. - Chasing an already-sent request. > [!IMPORTANT] > What most changes an estimate and almost nobody knows: **cost follows the action, not the recipient**. A bulk send to three hundred people consumes once, not three hundred times. If you were calculating per recipient, you are pricing it far higher than it is. ## How to find out exactly what it was 1. **Open the breakdown on the credits screen.** 2. **Sort by item, not by date: spend concentrates in two or three things.** 3. **Compare with last month; what changed is what needs explaining.** > [!WARNING] > If a charge is explained by none of this, check it against the activity log before assuming a billing error. Spend nobody recognises deserves knowing who launched it. > [!NOTE] > Some items have a declared price and are not charged today. A name appearing in a list does not mean you are being charged for it. **Can I see the detail per action?** Yes, each charge is recorded with its reference. **Is anything refunded if I void a send?** No: the send already happened. **Do reminders cost extra?** Chasing an already-sent request is not charged again. ## Ejemplos **A company estimates the annual amendment for 300 staff by multiplying by 300.** - Checks that a bulk send counts as one action → The estimate drops substantially and the decision changes. **Consumption appears that nobody recognises.** - Checks which activity generated it and when → The charge has a name and a date. **An action is repeated and consumes twice.** - Checks first whether it already happened → You stop paying for the same thing. **An automated process generates consumption overnight.** - Reviews which scheduled activities run → Automated spend becomes known. **Somebody on the team consumes unknowingly.** - Checks consumption by user → The conversation happens with the right person. **Consumption rises in a specific period.** - Compares with the same previous period → The increase is explained. --- --- id: KB-CD-010 url: https://app.codecontract.io/help/credits-and-billing/planning-a-years-consumption idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-003, KB-CD-009] citadoPor: [KB-CD-014, KB-CD-020] --- # Planning a year's consumption _Count actions, not suppliers or users, and anticipate the three peaks._ **Responde a:** budgeting annual consumption · how many credits will i need per year · planning platform spend · estimating credit usage Estimates nearly always fail for the same reason: they are calculated per supplier or per user, and consumption does not work that way. It follows executed actions, and those cluster at specific moments of the year. ## How to count 1. **Count the recurring actions in a normal month** — Onboardings, signature sends, documents uploaded and read. That is your floor. 2. **Multiply by twelve** — That is the bulk and it tends to be fairly stable. 3. **Add the peaks separately** — That is what throws everyone's estimate off. ## The three peaks almost everyone has | Peak | When | What triggers it | | --- | --- | --- | | Annual supplier renewal | Usually January or the start of your year | One send per supplier, plus reminders | | Season or peak trading | By sector | Staff onboarding in a few weeks | | Mass send to all staff | Agreement changes, amendments | One send, even to three hundred | > [!IMPORTANT] > The third is the most overestimated and it works in your favour: a bulk send counts as **one** action, not one per recipient. If you are budgeting the annual amendment for three hundred employees as three hundred send credits, the real figure is much lower. > [!WARNING] > The most underestimated is the second. Sixty onboardings in one week of season consume more than three normal months, because each onboarding is several actions: creating, sending, uploading and reading documents. ## What to review mid-year **En corto** - Whether real consumption runs above your estimated floor, and why. - Whether one process accounts for more than half. - And whether SMS is on by default where it was not needed. > [!NOTE] > Buying for a whole year at once only makes sense if the licence covers that period: credits do not expire with time, but they cannot be spent if the licence lapses. **Can I adjust mid-year?** Yes, topping up is immediate. **Is it worth buying extra?** Enough not to stop mid-batch; beyond that it adds nothing. **Can I see consumption per process?** Yes, and it is what explains the peaks. ## Ejemplos **A company budgets the year by multiplying its supplier count.** - Counts actions in a normal month and adds the three peaks separately - Checks that a bulk send counts as one action → The figure drops substantially and the budget stops being oversized by mid-year. **The year is estimated from a quiet month's consumption.** - Separates the peak month from a normal one → The forecast holds for the year. **Expected growth is not accounted for.** - Adds the growth assumption → The estimate does not fall short mid-year. **Planning happens without knowing what each process consumes.** - Checks consumption by activity type → The forecast rests on your own data. **A new process is introduced without estimating its consumption.** - Estimates before rolling it out → The impact is known beforehand. **Management asks for an annual figure.** - Brings the per-activity calculation and the assumption → The figure is explicable. --- --- id: KB-CD-011 url: https://app.codecontract.io/help/credits-and-billing/licence-and-credits-how-they-differ idioma: en categoria: creditos audiencia: administrador nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-005, KB-CD-004] citadoPor: [KB-CD-021] --- # Licence and credits: how they differ _Two different things that get confused, and one of them can block the other._ **Responde a:** difference between licence and credits · i have credits but it will not let me · licence expired what happens to my credits · what is the annual fee and what is pay per use There are two concepts and they are paid for separately. Confusing them causes most of the surprises: someone checks the balance, sees it full, and cannot understand why the platform will not let them do something. ## What each one is | Concept | The licence | Credits | | --- | --- | --- | | What it enables | Being able to use the platform | Executing specific actions | | How it is paid | Per period | By consumption, bought and spent | | When it runs out | When the period ends | When they are used up | | If missing | No actions can be executed | No actions can be executed | > [!IMPORTANT] > The last row is the key one and the one that surprises: **credits do not expire with time, but they cannot be spent if the licence is not current.** Having a balance is not enough; you need both. ## What happens when the licence lapses **En corto** - Credits are still there, nothing is lost. - What was already done stays accessible and verifiable. - But new actions stop until you renew. In other words, you lose nothing: it pauses. On renewal, whatever balance you had is still available and you carry on where you were. > [!WARNING] > This matters a lot when planning. Buying credits for two years only makes sense if the licence will cover those two years; otherwise you are prepaying for something you cannot use until you renew. ## How to tell which of the two is blocking you 1. **Check the balance first** — If it is zero, that is it, and topping up solves it. 2. **If there is balance and it still refuses, check the licence status** — This is the confusing case, because the balance seems to say all is well. 3. **And check permissions** — Sometimes it is neither: that user simply cannot perform that action. > [!NOTE] > All three are checked in a minute, in that order. Starting with the third is what turns a trivial incident into an afternoon. **Do credits expire?** Not with time. What expires is the licence, and without it they cannot be spent. **Are they refunded if unused?** They are not lost: they stay in your name for when the licence is current. **Can I consult old material without a licence?** What was already generated and is verifiable stays verifiable; what stops is doing new things. ## Ejemplos **A company sees plenty of balance and cannot understand why sending for signature fails.** - Checks the licence status and finds it lapsed the week before - Renews → Work resumes with the same balance, with no credits lost. **Balance is bought and the problem was the licence.** - Checks what is actually blocking → The real problem gets solved. **It is assumed more users consume more balance.** - Checks what depends on each concept → The team grows without surprises. **The licence expires with balance available.** - Records its expiry with a warning → Work does not stop with balance to spare. **The year is planned counting only balance.** - Includes both concepts in the forecast → The estimate is complete. **Nobody knows what the licence covers.** - Checks what each one includes → Decisions are taken knowingly. --- --- id: KB-CD-012 url: https://app.codecontract.io/help/credits-and-billing/splitting-the-cost-between-group-companies idioma: en categoria: creditos audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-006, KB-ET-014] citadoPor: [KB-CD-020] --- # Splitting the cost between group companies _When one company pays and three use it, and it has to be justifiable._ **Responde a:** recharging cost to subsidiaries · splitting costs between group companies · justifying usage per entity · intercompany billing of shared services In a group it is common for one company to contract and the others to use. It works fine until someone — the tax adviser, an audit, a minority partner in one subsidiary — asks for the split to be justified. And then you need a criterion and data behind it. ## The three ways to split | Criterion | When it fits | What you need | | --- | --- | --- | | By actual usage | When use differs a lot between entities | The breakdown by organisation or area | | By a fixed key | When use is similar and a split would be arguable | A written, stable criterion (headcount, turnover) | | Mixed | Part fixed, part by usage | Both, and the reasoning | > [!IMPORTANT] > What does not work is having no criterion. Splitting "as always" with no document explaining it is what gets questioned in an inspection or when a new partner joins a subsidiary. ## How to back it with data 1. **Separate what can be separated** — If each entity is its own organisation, consumption is separated at source. 2. **If they share one, separate by area or team** — It allows attribution without splitting operations. 3. **Pull the data for the same period you bill** — Monthly with monthly. Reconstructing at year end is where discrepancies appear. 4. **And write the criterion down, once** — With a date. Changing it later is legitimate; changing it without a trace is not. > [!WARNING] > If you are considering separate organisations solely to split costs, think twice: running five organisations costs more than the split it solves. Separate for other reasons, and use the breakdown for the split. ## What the adviser usually asks for **En corto** - The criterion, written and dated. - The period's usage data, not an estimate. - And consistency: the same criterion every month. With those three the split defends itself. Without them, every financial year reopens the argument from scratch. > [!NOTE] > Beyond the split, the breakdown does something almost nobody looks at: it reveals that one area accounts for half the total. That information is more useful for managing than for billing. **Can each entity have its own balance?** If they are separate organisations, yes: each holds its own. **What if a subsidiary leaves the group?** With separate organisations it is clean; if they shared one, the separation needs planning. **Is an equal split acceptable?** If usage really is similar and it is written down, it is a valid criterion. ## Ejemplos **A group splits the cost equally between four companies and one objects.** - Pulls the usage breakdown by area for the last quarter - Writes a mixed criterion and applies it from the next period → The split stops being argued and the company that barely used it pays accordingly. **Cost is split equally between companies.** - Checks each one's real consumption → The split rests on data. **One group company says they spend less.** - Shows them their consumption breakdown → The conversation closes on the figure. **Each company wants its own control.** - Separates consumption by organisation → Each one sees their own. **The split is done by hand every month.** - Checks the breakdown already calculated → The close stops taking an afternoon. **A new company joins the group.** - Adds its consumption to the same breakdown → The split keeps working the same way. --- --- id: KB-CD-013 url: https://app.codecontract.io/help/credits-and-billing/we-spent-three-times-more-this-month idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-003, KB-CD-009, KB-CD-007] citadoPor: [KB-CD-015, KB-CD-016, KB-CD-017, KB-CD-018] --- # We spent three times more this month _Four possible causes, and how to tell them apart in ten minutes._ **Responde a:** credit consumption has spiked · why did we spend more this month · unexpected platform consumption · controlling a rising spend Consumption jumps and the first reaction is to assume something is broken. It rarely is: it is almost always one of these four, and all four are told apart by looking at the breakdown rather than the invoice. ## The four causes, by frequency | Cause | How to recognise it | What to do | | --- | --- | --- | | A campaign or activity peak | The rise concentrates in a few days | Nothing: it was expected, and worth noting for next year | | A new automatic rule | The rise starts the day it was switched on | Check how often it fires | | An expensive channel set as default | One specific action type rises | Keep the expensive channel only where needed | | Resends and repeats | Many actions of the same type to the same recipient | Check the status before resending | > [!IMPORTANT] > The second surprises most and is easiest to miss: a rule that looked harmless can fire hundreds of times a month. Each firing consumes exactly as if a person did it, and nobody sees it because nobody is doing it. ## How to look, in order 1. **The breakdown by action type** — It says what rose: sends, reads, uploads, certifications. 2. **Then by area or process** — It says who did it, usually one place. 3. **And the date it started** — If it started on a specific day, find what was switched on that day. > [!WARNING] > Beware jumping to "someone is misusing this". In the vast majority of cases it is a well-meaning automation or a campaign nobody announced, and starting by blaming a person spoils the conversation without fixing anything. ## What to leave in place afterwards **En corto** - A monthly glance at the breakdown, not just the total. - A note of planned campaigns, so a peak is not mistaken for a problem. - And a review of active automatic rules twice a year. With that, an expensive month stops being a surprise and becomes something you already knew was coming. > [!NOTE] > If the rise comes from a bulk send, remember a send to two hundred counts as one action. If you are seeing two hundred, it was not a bulk send: it was two hundred sends, and that is a method problem, not a pricing one. **Can a spending limit be set?** You control top-ups and review the breakdown; the real brake is knowing what consumes. **Does the assistant's work consume?** Yes, exactly as if a person did it. **What about failed actions?** It depends on the type; the breakdown shows it, and it is worth checking. ## Ejemplos **A company sees consumption triple and suspects a fault.** - Checks the breakdown by type and by date - Finds a rule switched on the 3rd that fires hourly → Adjusts the rule and consumption returns to normal, with nobody blamed. **Consumption triples and nobody knows why.** - Compares the breakdown with the previous month → The difference is located. **A new process came in without flagging its impact.** - Reviews which activities it added → The rise has a cause. **A one-off campaign explains the spike.** - Separates campaign consumption from the ordinary → The month reads correctly. **Somebody repeats actions out of unfamiliarity.** - Checks consumption by user → Training goes where it is needed. **The rise is discovered on the invoice.** - Reviews consumption during the month → The correction arrives in time. --- --- id: KB-CD-014 url: https://app.codecontract.io/help/credits-and-billing/explaining-the-cost-to-management idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-010, KB-CR-013] citadoPor: [KB-CD-007] --- # Explaining the cost to management _The figure does not convince on its own. What convinces is what it is compared against._ **Responde a:** justifying platform spend · return on documentation investment · defending the budget · comparing cost with what it saves When someone in management asks what this costs, the usual answer is a monthly figure. And a figure on its own, with nothing beside it, always looks expensive: there is no context to judge it against. ## The three comparisons that work | Comparison | How to calculate it | When it convinces | | --- | --- | --- | | Hours recovered | How often it was done by hand × time × hourly cost | Always; the easiest to accept | | An incident avoided | What the last documentary problem cost | When there was a recent one everyone remembers | | What a client requires | The contract that is not signed without this | The most powerful, and the least used | > [!IMPORTANT] > The third turns the conversation from cost into requirement. If a large client demands to audit your documentation, this stops being an efficiency improvement and becomes a condition for invoicing that client — and that is no longer discussed at the same table. ## How to prepare it without inventing anything 1. **Count the real work it replaced** — "Chasing forty suppliers every quarter" is measurable; "we are more organised" is not. 2. **Use real consumption, not estimates** — With the breakdown. A figure that can be opened up gets questioned less. 3. **And say what has not changed too** — It lends credibility to the rest and pre-empts the awkward question later. > [!WARNING] > Do not promise headcount savings. They almost never happen — people stay, doing something else — and promising it turns a real improvement into a broken promise remembered for years. ## What management usually asks **En corto** - "What happens if we drop it?" — Answer with what you would stop being able to prove, not with what it would cost. - "Can we spend less?" — Yes, and the breakdown says exactly where. - "Do people actually use it?" — The best question, answered with usage data. The third is the one always worth being able to answer. A tool that is paid for and unused is a cost; one used daily by fifteen people is infrastructure. > [!NOTE] > If consumption is split between group companies or departments, bring that breakdown too: many objections disappear when each area sees its own instead of an abstract total. **What if the saving is not obvious yet?** Say so: three months in, the honest thing is to show usage rather than return. **How do I value an avoided risk?** With what it cost last time it happened, if you have the figure. **Should the full breakdown be shown?** Yes. What cannot be opened always looks more expensive than it is. ## Ejemplos **A manager presents the monthly cost and management finds it high.** - Adds the chasing hours it replaces and their largest client's requirement → The conversation shifts from what it costs to what would happen without it. **The cost is explained without comparing it to anything.** - Compares it with the hours previously spent → The conversation has two figures. **Management asks what is obtained in return.** - Brings consumption alongside the period's output → Cost is read next to what it produced. **One month's rise is presented without context.** - Explains which campaign or process caused it → The spike stops being an alarm. **Nobody knows which department consumes what.** - Presents the breakdown by department → The conversation happens with each of them. **A reduction is asked for without knowing where.** - Shows which activities weigh most → The reduction is decided on a basis. --- --- id: KB-CD-015 url: https://app.codecontract.io/help/credits-and-billing/what-does-not-consume-credits idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-002, KB-CD-013] citadoPor: [KB-CD-005] --- # What does not consume credits _The list of what you can do without watching the balance, which is longer than people think._ **Responde a:** what is free on the platform · does viewing documents use credits · does the signer pay anything · does downloading a report consume Almost all documentation about credits explains what gets charged. The side effect is that many people end up using the platform with the handbrake on: not searching just in case, not opening a file just in case, not showing something to a colleague just in case. The opposite list is worth having. ## What does not consume | Action | Comment | | --- | --- | | Logging in, browsing and consulting | Opening files, viewing documents and checking history | | Searching your documents | Content search is not a charged action | | A third party supplying or signing | Whoever receives the request pays nothing: consumption is on the sender | | Downloading a report already generated | Generating it counts; downloading it again does not | | Receiving the daily digest | Sending is not counted; what counts is generating it | | An agent thinking | Its actions count; the internal processing does not | > [!IMPORTANT] > The third row is worth saying out loud when you work with small suppliers. It is their first question — "is this going to cost me anything?" — and the answer is no: they enter by their link, upload theirs or sign, and need no account, no licence and no balance. ## What does consume, in short **En corto** - Going outward: every send, reminder or call. - Asking the AI to work: reading a document, extracting data, answering. - And leaving evidence: certifying, sealing or generating a verification QR. It is an easy pattern to remember: you are charged when the platform does something for you outward or with AI. Looking at what is already inside, no. > [!WARNING] > The nuance that confuses anyone reading the credit policy: it lists concepts that are not being charged today. **The source of truth is your consumption breakdown, not the price list**: if a concept does not appear in the month's breakdown, you were not charged for it, whatever the table says. And if it ever started being charged, it would show up there. ## What to tell the team 1. **Search without fear** — The cost of not finding something is far higher than any search. 2. **Do not resend out of habit** — There it does count: every resend is a new send, and it is usually avoidable by checking the status. 3. **And run trials on a real case** — Repeating the same send twenty times to demo it does consume. > [!NOTE] > If someone on your team avoids using the platform "to save credits", that costs more than the spend it avoids: the documentation ends up outside, in an inbox, and that is where it gets lost. **Does checking history cost anything?** No. Consulting what is already stored is not a charged action. **What if a supplier uploads ten documents?** What is counted is the request you sent, not each file they supply. **How do I know exactly what I was charged for?** The breakdown: it shows action, date and area. It answers any doubt in this article. ## Ejemplos **A team avoids searching and opening files "to save credits".** - Checks the breakdown and sees consulting is not a charged action → They stop working with the handbrake on and the month's consumption does not change. **The team avoids consulting in case it consumes.** - Checks which activities do not consume → Usage stops being held back out of caution. **People search local folders rather than looking here.** - Confirms that searching does not consume → Work returns to where the information is. **Inviting a colleague is avoided for fear of cost.** - Checks what depends on licence and what on usage → The team comes in without surprises. **Documents are downloaded to avoid reopening them.** - Confirms which actions are free → Information stops being duplicated outside. **Decisions are taken without knowing what is free.** - Checks the list before deciding → The decision uses the fact. --- --- id: KB-CD-016 url: https://app.codecontract.io/help/credits-and-billing/the-cost-of-doing-things-twice idioma: en categoria: creditos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-013, KB-PR-013] citadoPor: [KB-CD-019, KB-CD-020] --- # The cost of doing things twice _Almost all avoidable consumption comes not from heavy use but from repetition._ **Responde a:** reduce credit consumption · why do we spend more than expected · avoiding duplicate sends · uploading the same document twice When a company wants to spend less, the first idea is usually to use the platform less. That is almost always the wrong answer: avoidable consumption is not in what you do once, it is in what you end up doing two or three times. ## The four usual repetitions | Repetition | Why it happens | What prevents it | | --- | --- | --- | | Resending something that did go out | Nobody checks the status before repeating | Check whether it shows delivered or opened | | Uploading the same document twice | It arrives by two routes: email and link | Have the third party supply by their link and nobody else upload it | | Asking again for what was already supplied | The request stays open although the document is there | Close the request on receipt | | Redoing a badly targeted campaign | It was launched against an old list | Review the list beforehand, not after | > [!IMPORTANT] > The first is by far the commonest and the only one solved by changing nothing: **before resending, check the status**. A send showing delivered and opened does not need repeating, and the resend counts as a new action just like the first. Most of the time the problem was not that it never arrived, but that it arrived to the wrong person. ## What counts and what does not, so you do not optimise blindly **En corto** - Every send counts, including resends and manual reminders. - Uploading a document counts; consulting it afterwards as often as you like does not. - And asking the AI to re-read something it already read does not appear as a charge in the breakdown today. Read that last one with the usual criterion: **the source of truth is your breakdown**, not a price list. What does not appear there was not charged to you. > [!WARNING] > Beware the optimisation that costs money: stopping reminders to save credits. A reminder costs one action; a supplier delivering two weeks late can cost you a stopped site. The saving is in not repeating what already worked, not in giving up on chasing whoever has not replied. ## How to spot where you are repeating 1. **Look at the breakdown by action type** — If sends far exceed open requests, there are surplus resends. 2. **And by recipient** — Three sends to the same contact in a week are almost always the same matter. 3. **Ask whoever sends them** — They usually know exactly why they resend: normally they do not trust the status. > [!NOTE] > If the team resends because they do not trust what the send status says, that is the problem to fix — not the consumption. Showing once how to read the status saves more than any savings policy. **Is sending to several at once cheaper?** Yes: a send to two hundred counts as one, not two hundred. **What if a document arrives corrupted and must be re-uploaded?** That is a genuine new upload; hence asking for a usable original. **Does deleting duplicates save anything?** Nothing retroactive: what was consumed is already counted. It helps clarity, not spend. ## Ejemplos **A company sees high consumption and decides to send fewer reminders.** - Checks the breakdown and finds the excess was resends of the same send - Shows the team how to check status before repeating → Consumption falls and chasing keeps working, which is what they actually needed. **A process is relaunched because nobody knows whether it went out.** - Checks the status before repeating → You stop paying twice for the same thing. **Two people request the same thing from the same supplier.** - They work on the same file → The supplier receives one request, not two. **A document that was already processed is read again.** - Checks whether it already has extracted data → The process is not repeated without reason. **A document is sent for signature twice just in case.** - Checks the signature status → The signer does not receive the same document twice. **A campaign is redone because there is no record it was sent.** - Checks the send history → The cost of doubt disappears. --- --- id: KB-CD-017 url: https://app.codecontract.io/help/credits-and-billing/who-should-be-able-to-spend idioma: en categoria: creditos audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-013, KB-AD-014, KB-CD-008] citadoPor: [KB-CD-003] --- # Who should be able to spend _Almost nobody decides this, and then it shows up in the breakdown. The three profiles and what to leave each._ **Responde a:** limit who can send · control spend per user · who can launch a campaign · permissions and credit consumption Consumption is not generated by "the company": it is generated by specific people doing specific things. And since it is almost never decided who may do what from that angle, the first time someone opens the breakdown they find that 60% comes from one person who did not even know they were spending. ## The three profiles by what they can trigger | Profile | What actions they generate | What works | | --- | --- | --- | | Whoever runs the day to day | Sends, reminders, uploads: high volume, low risk per action | No limits, with visibility | | Whoever launches to many | Campaigns and bulk sends: few actions, wide reach | They should know it is one action and how many it reaches | | Whoever switches on automations | Rules that fire by themselves, many times | Here yes: have someone review first | > [!IMPORTANT] > The third row is the only one genuinely worth putting a hand in front of, and not because of the action's cost — it is the same as any other — but because **it is the only one that multiplies without anyone touching it again**. A person sending consumes as they work; a misaimed rule consumes for as long as it is on, weekends included. ## What works better than a limit 1. **Let each area see its own consumption** — Seeing the figure changes behaviour more than any permission: nobody wants to be the line that stands out. 2. **Warn about what multiplies, not what adds** — A send to two hundred is one action; an hourly rule is seven hundred a month. 3. **And review who generated what monthly** — Not to point fingers: to discover the process nobody knew existed. > [!WARNING] > Beware the intuitive reaction of restricting whoever spends most. It is nearly always whoever works most with the outside world — the person chasing suppliers, the one sending for signature — and limiting them saves nothing: it moves the work elsewhere, usually to email, where no record remains. **If someone spends a lot and their job justifies it, the figure is not a problem: it is a description of their role.** ## When narrowing does make sense **En corto** - When an outsider has access and could send on your behalf. - When an intern or temporary person is learning on real cases. - And when an integration can trigger actions with no person behind it. The third surprises people most on review: an integration that creates or notifies generates actions like a person, and it does not tire or take holidays. > [!NOTE] > Everything executed is attributed to whoever did it — person, rule or integration — so the consumption conversation can be had with data rather than impressions. It is the difference between "we spend a lot" and "this rule has run seven hundred times this month". **Can a per-user cap be set?** What exists is visibility and permissions over actions; the real brake is knowing who generates what. **What if someone spends by mistake?** It is usually a rule, not a person: look at the automatic side first. **Should consumption be shown to the whole team?** Their area's, yes. The company total, only to whoever decides. ## Ejemplos **A company sees high consumption and considers limiting whoever sends most.** - Checks the breakdown by origin and finds an hourly rule switched on two months ago → Adjusts the rule and leaves the top sender alone — they were the one getting the most deliveries. **Anyone can launch actions that consume.** - Defines who can do what → Spend has known owners. **Somebody new launches a campaign by mistake.** - Limits bulk actions to the right people → The big mistake stops being possible. **Nobody knows who generated a specific consumption.** - Checks consumption by user → The conversation happens with the right person. **Broad permissions are granted to get past a problem.** - Grants only what is needed → Access matches the role. **A department asks to be able to spend on its own.** - Separates consumption by department with its own limit → Each one decides within their own. --- --- id: KB-CD-018 url: https://app.codecontract.io/help/credits-and-billing/the-spend-that-runs-on-its-own idioma: en categoria: creditos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-013, KB-CD-003, KB-CD-021] citadoPor: [KB-CD-006] --- # The spend that runs on its own _What gets consumed with nobody clicking anything, and why automating well starts with knowing what repeats._ **Responde a:** credits used without doing anything · how much does automating notices cost · do webhooks use credits · why does usage climb every month What you click by hand is easy to estimate: you know how many documents you request a month. What is configured once and then runs on its own is estimated badly, because nobody triggers it and nobody counts it. It is not expensive: it repeats. ## What runs on its own, and what it costs | What is automated | When it consumes | Worth knowing | | --- | --- | --- | | Notice to your system on each event | Once per delivered event | If the rule fires on every status change, it multiplies | | Automatic process rules | Each time the rule applies | A loosely scoped rule applies more often than you think | | Daily summary | When it is produced | Sending it adds nothing | | Sync with your folder | Per sync requested | Not per document copied | | Automatic reminder to a signer | Does not consume | One of the few repeating things that is free | | Reminder to a contact | Does consume | And that is the contrast almost nobody expects | > [!IMPORTANT] > Those last two rows sum up the whole criterion: **chasing someone already signing costs nothing; asking a third party again does**. It is not arbitrary — the first closes something already under way, the second is a fresh outward communication. If you automate chasing, that difference is what decides the month-end bill, and it shows on no screen until it has happened. ## The other rule that orders everything else **En corto** - Producing costs; looking again at what was produced does not. - Downloading a report, a ZIP or a document that already exists does not charge again. - Searching your own material, seeing who accessed it or checking a seal is free. - And one action is one action: asking ten contacts for something is one, not ten. > [!WARNING] > Careful with what looks like a repeated charge and is not: **some processes are recorded step by step**. An automated call leaves a record of dialling, of transcribing and of storing; a job by the agent that browses on your behalf, of launching it, of logging what it did and of uploading the result. They appear as separate lines in the detail — deliberately, so each one can be audited — and added together they are what that whole task costs. ## How to size it before switching it on 1. **Count events, not features** — «Notify the ERP» says nothing; «four status changes per file» does. 2. **Multiply by your real volume for a month** — Using the busiest month of the year, not the average. 3. **Scope the rule to the event that actually matters** — Half of automatic notices are read by nobody. 4. **And review it the following month** — It is the only way to see what fired more than it should. > [!NOTE] > Each organisation can have its own consumption policy, so your account's detail overrides any general list. What does not change is the criterion: you are charged for what the platform does outwards or produces for you, not for consulting what is already yours. **Can I limit who switches automations on?** Yes, and it is worth it: it is what stops ownerless spend growing. **Does a notice that fails and retries count?** Check your account detail: every recorded delivery appears there. **Is automating worth it, then?** Nearly always: a chase that goes out on its own costs less than the call it saves. ## Ejemplos **A company wires notices into its ERP on every status change of every file.** - Counts a busy month's events before switching it on and scopes the rule to two statuses → The notice arrives when it adds something, and automatic spend stops being a monthly surprise. **A scheduled process consumes every day.** - Reviews which activities it generates → Automated spend becomes known. **A process nobody needs is left running.** - Reviews what is scheduled periodically → What nobody uses gets switched off. **An integration generates consumption unwatched.** - Checks consumption by source → Automated spend has a name. **Consumption rises with nobody having done anything.** - Compares the breakdown with the previous period → The increase is located. **An automatic reminder fires more often than intended.** - Reviews the configured frequency → Consumption matches what is needed. --- --- id: KB-CD-019 url: https://app.codecontract.io/help/credits-and-billing/if-something-fails-was-it-still-charged idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-009, KB-CD-016] citadoPor: [KB-CD-003] --- # If something fails, was it still charged? _The question that follows the first bounced message, and the rule that answers it for every case._ **Responde a:** the email bounced and I was charged · are credits used if a send fails · does retrying consume again · charged even if they never got it You send a request, the address was wrong and the message bounces. The question asks itself: if it never arrived, why does the usage show? The answer is consistent, even if it does not look that way the first time. ## The rule, and how it applies | What happened | Was the action performed | How it ends up | | --- | --- | --- | | The message went out and bounced | Yes: it was prepared and sent | Recorded as done, and the detail shows it | | The recipient never opened it | Yes | Same: what was done was sending it | | You cancelled before sending | No | There was no action | | Retrying after fixing the address | Yes, it is another action | It counts as the send it is | | Viewing or downloading what already exists | Not an action of this kind | It does not add up | > [!IMPORTANT] > The logic behind all this is not the outcome, it is the work done: **what is recorded is what the platform does for you towards the outside, not what the recipient decides to do**. Whether they open it, reply or bin it is not in your hands or anyone's here. If usage depended on the other side answering, half of what you do could not be measured — and the practical consequence is the opposite of what it seems: **fixing before sending is worth more than retrying afterwards**. ## How repeat spend is avoided 1. **Check the address before the first send** — Especially for new contacts or ones imported from another system. 2. **On a large batch, test with two first** — If the template has an error, it shows there and not four hundred times. 3. **And fix the contact card, not just the send** — Otherwise the next person to write hits the same thing. > [!WARNING] > A detail worth knowing before retrying in the heat of the moment: **what has gone out is not undone by repeating it**. A sent message is sent, and resending does not replace it: there are two, and the recipient sees both. If the aim was to correct something, cancel the earlier one where possible and explain it in the new one, rather than resending three times hoping the good one sticks. ## Where it is actually checked **En corto** - Your account detail shows each action with its date and what it relates to. - Each organisation can have its own policy, so that detail overrides any general list. - And if something does not add up, that is exactly what support needs: the specific line, not the monthly total. > [!NOTE] > If one send appears several times and you do not recognise the retries, look for an automatic rule behind it: what runs on its own leaves its trace too, and it is the commonest explanation. **What if the failure was the platform's?** That is a different matter: show support the line and it gets reviewed. **Does cancelling before sending cost anything?** No: what never went out is not an outward action. **Does a batch of four hundred count as four hundred?** No: a bulk send counts as the single action it is. ## Ejemplos **A company resends a request four times to a mistyped address.** - Fixes the contact card before the next send and tests the batch with two → It lands on the first attempt and the same spend stops repeating over a one-character error. **An action fails and nobody knows whether it consumed.** - Checks that activity's breakdown → The doubt is settled by the record. **It is repeated after a failure just in case.** - Checks the status before repeating → Nothing is consumed twice over one failure. **A process is cut off halfway.** - Checks what actually ran → It resumes from where it was. **Consumption is disputed over a failed action.** - Provides that activity's breakdown → The dispute is resolved precisely. **An error repeats and consumes each time.** - Reviews the cause before retrying → The next attempt makes sense. --- --- id: KB-CD-020 url: https://app.codecontract.io/help/credits-and-billing/what-the-learning-month-costs idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-016, KB-CD-010, KB-CD-012] citadoPor: [KB-CD-002] --- # What the learning month costs _The first month costs more per result achieved, and that is not a fault: it is what you pay once._ **Responde a:** we spent a lot in the first month · how much does a pilot consume · cost of learning to use it · budgeting the first months Looking at the first month's usage, the usual reaction is to think this will be expensive. It rarely is: what you are seeing is not the cost of working, it is the cost of learning to work — and that is paid once. ## Where the extra early spend comes from | Cause | Why it happens | When it disappears | | --- | --- | --- | | Requests that had to be redone | The message was not clear first time | As soon as the wording is fixed | | Test sends to colleagues | You need to see it from the other side | In the first week | | The same thing requested twice | Two people did not know the other was asking | Once you split who asks for what | | Documents uploaded and re-uploaded | You learn quickly which format works | Almost immediately | > [!IMPORTANT] > Worth knowing before drawing conclusions from month one: **that usage is not spread evenly, it clusters in the first few days**. Divide the month's spend by four weeks and project a year and the figure is an exaggeration — and it is exactly the calculation taken to management when the first invoice lands. The number to plan with is week four's, not the month's average. ## How to shorten that month without skipping the learning 1. **Run the full circuit once, on a small real case** — One complete run teaches more than ten half ones. 2. **Before a large batch, send to two** — If the wording or the template is wrong, it shows there. 3. **Split who asks for what from the start** — Asked twice is the silliest spend of all. 4. **And fix the message the moment anyone asks** — Every doubt resolved is saved on all later sends. > [!WARNING] > There is an early cost that appears in no account and is the dearest of all: **the things done outside the system because the process was not ready yet**. Documents requested by separate email, papers left on a desk, a batch handled by hand «just this once». That consumes nothing and costs a great deal, because it has to be redone or you live with a hole in the record. ## Which number to budget with **En corto** - A normal month's, once nobody is asking how it works. - Counting outward actions, not people or stored documents. - And with the busiest month of the year in view, not the average. > [!NOTE] > Each organisation can have its own consumption policy, so your account's detail overrides any general estimate. What does not change is that the first month is no basis for projecting anything. **How long until it settles?** Usually the second full cycle of the process, not the second month. **Should spend be capped while learning?** Yes, and it is easy: decide who can launch large sends. **What if month two is still high?** Then it is no longer learning: look at what is being repeated. ## Ejemplos **A company projects the year by dividing its first month's spend by four.** - Uses week four as the reference and checks it against the year's busiest month → The budget stops being inflated by the first days' test sends. **The first month consumes more than expected.** - Counts the learning month separately → The year's forecast is not distorted. **Actions are repeated out of unfamiliarity.** - Checks consumption by user and trains where needed → The learning curve shortens. **Testing happens in production and consumes.** - Tests with a small, real case → Learning costs little. **The tool is dismissed over the first month's cost.** - Compares with the second month's consumption → The decision uses the settled figure. **Nobody knows how long the initial overspend will last.** - Compares consumption month by month → You see when it settles. --- --- id: KB-CD-021 url: https://app.codecontract.io/help/credits-and-billing/is-this-going-to-cost-me idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-002, KB-CD-009, KB-CD-011] citadoPor: [KB-CD-018] --- # Is this going to cost me? _Looking, searching and organising costs nothing. What costs is what goes outwards or through the AI — and you can tell before clicking._ **Responde a:** does this use credits · will i be charged for this · how much does sending a request cost · can i try without being charged **The short rule: looking costs nothing; the platform DOING something for you does.** Signing in, searching, browsing and downloading something that already exists is free. Every action the platform performs and records —sending, creating, uploading, AI reading, certifying, signing, generating a report— consumes credits. ## The practical version | What you do | Does it cost? | | --- | --- | | Signing in, looking, searching, organising folders | No | | Downloading something already generated | No | | **Sending something to someone outside** | **Yes** | | **Creating a process, uploading a document, AI reading it** | **Yes** | > [!IMPORTANT] > **What consumes is the ACTIVITY, not each item: asking four contacts for a document consumes once, not four times.** A bulk send counts as a single activity however many recipients it carries, and approving twenty validations at once likewise. It is the doubt that holds people back most at the start and the answer is in your favour — which is why splitting work into small sends «to spend less» does the opposite. ## If you are unsure before clicking 1. **Ask whether the platform will do something or merely show it to you** — Consulting what already exists costs nothing, however often you look. 2. **Count activities, not recipients or documents** — Four contacts on one request is a single activity. 3. **And if still unsure, check the consumption afterwards** — What was charged and why is recorded: you can verify rather than trust. > [!WARNING] > Two things you will not discover by yourself. **One: the licence and the balance are different, and the one that blocks is the licence** — with a lapsed licence you cannot operate however much balance you hold, whereas running out of credits does not strand you mid-task. **Two: if an action fails on your side —a mistyped address, an illegible document— the work was still done.** Which is why redoing things is what really pushes up the month, more than the price of anything. **Can I try things without spending?** Looking and browsing, as much as you like. Creating a process is already an action and counts. **Will you warn me before charging?** What consumes is knowable beforehand and recorded afterwards, with its reason. **What if I run out of balance?** It does not cut you off mid-task. What does block is a lapsed licence. ## Ejemplos **Someone splits a request to ten suppliers into ten separate sends «to spend less».** - Checks that the request counts as one activity, not one per recipient → The consumption of ten activities becomes that of one, and the work also lands sooner. **People stop using the platform to look things up, fearing that looking costs.** - Checks that signing in, searching and downloading what exists consumes nothing → The file gets consulted when needed instead of loose copies being kept elsewhere. **There is doubt whether an action will consume.** - Checks what consumes before doing it → The doubt is settled beforehand rather than after. **Something is avoided just in case.** - Checks the list of what consumes → Usage stops being held back out of caution. **Consumption appears that nobody expected.** - Checks which activity generated it → The charge has an explanation. **An external partner does something and the charge is feared.** - Checks which activities count and which do not → The team works knowingly. --- --- id: KB-CD-004 url: https://app.codecontract.io/help/credits-and-billing/i-have-run-out-of-balance idioma: en categoria: creditos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-002, KB-CD-003] citadoPor: [KB-CD-007, KB-CD-009, KB-CD-011, KB-CD-005] --- # I have run out of balance _What stops, what carries on, and how to get moving again in five minutes._ **Responde a:** i have run out of credits · cannot send due to insufficient balance · what happens when credits run out · top up balance urgently It almost always happens mid-batch and in a hurry. The first thing to know is that nothing has broken: what already went out carries on. ## What stops and what does not | Keeps working | Waits | | --- | --- | | What was already sent, reminders included | New sends | | Signatures in progress | Automatic reading of new documents | | Viewing, searching and downloading | New SMS and WhatsApp | | A third party delivering or signing | — | > [!NOTE] > That third parties are unaffected is the important part: nobody outside learns you ran out, and whoever was signing can finish. ## How to get moving 1. **Top up from the credits screen.** 2. **Return to the batch that stopped and relaunch only for those left out.** 3. **Set the low-balance alert if you had not, so it does not happen mid-batch again.** > [!WARNING] > When relaunching, filter for those who received nothing. Sending again to people who already had it duplicates the request and confuses them. > [!IMPORTANT] > If it happened on a batch with a deadline — an amendment that had to go today — prioritise topping up and relaunching over investigating why it ran out. The breakdown can wait until tomorrow. **Is prepared work lost?** No, it is still there; it is only waiting for balance. **Can I go into negative balance?** It depends on your configuration. By default, no. **How long until it is available?** Topping up is immediate. ## Ejemplos **A batch of 400 amendments stops at 260 for lack of balance.** - Tops up - Relaunches filtered to the 140 who received nothing → All 400 go out the same day and nobody receives the document twice. **The balance runs out and work stops.** - Warns before reaching the threshold → Topping up happens with time to spare. **Nobody knows how much is left until something fails.** - Checks the balance regularly → Running out stops being a surprise. **It runs out at a critical moment.** - Estimates the peak month separately → The peak is covered in advance. **It is topped up and runs out again weeks later.** - Reviews which activity consumes most → The cause is tackled rather than the symptom. **An automated campaign empties the balance overnight.** - Reviews what is scheduled before launching → Consumption is decided rather than discovered. --- --- id: KB-CD-005 url: https://app.codecontract.io/help/credits-and-billing/what-credits-are idioma: en categoria: creditos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-002, KB-CD-004, KB-CD-015] citadoPor: [KB-CD-008, KB-PS-009, KB-CD-009, KB-CD-011] --- # What credits are _What they are for, who pays, and why not everything consumes them._ **Responde a:** what are code contract credits · how does the balance work · do i pay per signature · who pays for credits Credits are the unit you pay usage in: each action the platform performs for you consumes one. They sit alongside the licence — the licence grants access, credits pay for what you do with it. **En corto** - Only things going outward, or using an external service, consume. - Viewing, searching, organising and inviting your team is free. - The third party who signs or delivers is never charged anything. ## The rule, in one sentence If the platform **does** something — send, create, upload, read, seal, generate — it consumes. If it only **shows** what is already inside, it does not. | Action | Consumes? | | --- | --- | | Sending for signature, or a notice on any channel | Yes | | Creating or duplicating a process | Yes | | Uploading a document | Yes | | Reading with AI, certifying or generating a report | Yes | | Searching, filtering and downloading what is stored | No | | A supplier delivering or signing | No | > [!IMPORTANT] > That the third party pays nothing is not a commercial detail: it is what makes them deliver. If signing cost something, half your suppliers would not do it. > [!NOTE] > The balance belongs to the whole organisation, not to each person. And since cost follows the action rather than the recipient, a send to three hundred people consumes the same as one. **Do they expire?** Not with time. But they cannot be spent if the licence lapses, so in practice they depend on keeping it current. **What happens if they run out?** What was already sent continues; new things wait. Nobody outside notices. **Can I see where they go?** Yes, in the breakdown on the credits screen. ## Ejemplos **A company fears uploading its whole archive will be expensive. Rightly so: every upload consumes.** - Uploads only what is current, not twelve years of archive - Disables reading on types that yield no useful data → Uploads what will genuinely be consulted and stops paying to archive what nobody will open. **Balance is confused with licence.** - Checks what each one covers → Forecasting covers both concepts. **Balance is bought when what was missing was licence.** - Reviews what is actually blocking → The real problem gets solved. **Nobody knows which activities consume balance.** - Checks the breakdown by activity → The team works knowingly. **Balance is left over one month and short the next.** - Estimates the year with peak months separately → The purchase is sized better. **Planning happens without allowing for growth.** - Adds the growth assumption to the estimate → The forecast holds for the year. --- --- id: KB-CD-006 url: https://app.codecontract.io/help/credits-and-billing/attributing-cost-across-departments idioma: en categoria: creditos audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CD-003, KB-CD-002, KB-CD-018] citadoPor: [KB-CD-012] --- # Knowing which department spends what _To charge it back, or simply so each team sees its own._ **Responde a:** split spend between departments · know how much each team spends · attribute costs by area · consumption report by project The balance belongs to the organisation, so at month end there is one number and nobody knows where it came from. If you have to charge it back — or simply want each manager to see their own — spend has to be attributable, and that is decided before spending it, not after. ## What makes spend attributable **En corto** - That the work sits inside a team, not loose. - That processes have an owner, not whoever happened to launch them. - That large sends go out from the right place. ## How to set it up 1. **One team per area with its own budget** — Not by org chart: by who answers for the spend. 2. **Each process inside its team** — A process shared across three areas is spend that cannot be split. 3. **Review the breakdown monthly** — Ten minutes. It is where you spot SMS left on by default in a three-hundred-person process. > [!WARNING] > Splitting the organisation into teams for accounting reasons has a real cost: it makes sharing templates and contacts harder. Do it if you genuinely will charge back; if it is curiosity, the per-process breakdown usually suffices. > [!IMPORTANT] > Charging back has an effect worth anticipating: the area paying starts avoiding the spend. If that means they stop sending SMS to people who do not read email, you will have saved credits and lost deliveries. > [!NOTE] > Before building anything, look at the current breakdown. Often 80% of spend comes from a single process, and knowing which one removes the need to split anything. **Can I cap a team?** It is controlled by permissions: someone who cannot launch large batches cannot spend in bulk. **Can it be exported?** Yes, with its dates, which is what finance needs. **Who is a third party's usage charged to?** Whoever launched the send. The third party never pays anything. ## Ejemplos **A group wants to charge spend back to its three divisions.** - Looks at the breakdown first - Finds 78% comes from supplier onboarding, which belongs to purchasing → Charges that process to purchasing and avoids splitting the organisation in three. **Cost is split between departments by eye.** - Checks real consumption by department → The split rests on data. **A department says they do not spend that much.** - Shows them their consumption breakdown → The conversation closes on the figure. **You want to know which process consumes most.** - Checks consumption by activity type → Optimisation goes where it matters. **Spend grows and nobody knows where from.** - Compares consumption across periods → The increase is located. **Each department asks for more balance without justification.** - Allocates according to recorded consumption → Allocation stops being a negotiation. --- --- id: KB-CD-001 url: https://app.codecontract.io/help/credits-and-billing/how-credits-work idioma: en categoria: creditos audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-001, KB-PS-001, KB-PR-002] citadoPor: [KB-CD-003, KB-CD-002, KB-CR-008] enLaApp: https://app.codecontract.io/credits --- # How credits work _What consumes credits and what does not, where to see the balance and what happens when it runs out._ **Responde a:** what consumes credits · how many credits does reading a document use · where do I see my organisation's balance · I have run out of credits what happens · how do I buy more credits Credits are the unit used to pay for actions with a real cost behind them: reading a document with AI, sending an SMS, sealing a piece of evidence. Almost everything else — creating processes, uploading files, inviting your team — costs nothing. **En corto** - Consumed by anything a third party charges for: AI reading, SMS, sealing. - Not consumed by using the platform: creating, organising, consulting or simple signing. - The balance belongs to the organisation, not to each user. - If it runs out, nothing done is lost: only paid actions stop being available. ## What consumes and what does not | Action | Consumes credits? | | --- | --- | | Reading a document with AI | Yes | | Sending an SMS or WhatsApp | Yes | | Sealing evidence in SmartCheck | Yes | | Creating processes, templates and folders | No | | Uploading or downloading documents | No | | Sending a notice by email | No | | Correcting an extracted field by hand | No | | Inviting users from your team | No | _The underlying rule: if a third party is charging behind it, it consumes; if it is the platform, it does not._ ## Where to see the balance In the credits section, along with the history of what they went on. That history is what lets you answer "why did we spend so much last month" without guessing: it is broken down by action and date. > [!WARNING] > If you are about to launch a large batch — two hundred requests with automatic reading — check the balance first. Running out halfway means redoing the review of whatever was left pending. ## What happens if they run out Actions that consume credits stop being available until you top up. Nothing already done is lost or reversed: documents remain, cases remain and completed signatures remain valid. What stops is anything new. ## Frequently asked questions **Do credits expire?** It depends on your plan. Worth checking before buying a large bundle in one go. **Does each user have their own balance?** No, the balance belongs to the organisation. What you can see is which action consumed it and when. **Can I set an alert when the balance gets low?** Yes, and it is recommended: finding out there is no balance after launching a batch is the worst moment. **Does signing consume credits?** The signature itself does not; what consumes is the SMS for an advanced signature, because the carrier charges for it. **Can the balance go negative?** It is a configuration option so an operation in progress is not cut off halfway. It is not on by default. ## Ejemplos **A company sees its credit spend triple and does not know why.** - Opens the consumption history by action and date - Sees the spike matches a 400-request campaign with automatic reading - Adjusts the low-balance alert for next time → An explanation backed by data in five minutes, instead of an argument about who spent what. **Nobody knows which activities consume and which do not.** - Checks the consumption breakdown by activity → Forecasting rests on what actually spends. **There is a fear that inviting more people will drive consumption up.** - Checks what depends on the licence and what on usage → The number of users stops being the unknown. **The balance falls and nobody knows why.** - Checks the consumption history → The spend has an explanation rather than a suspicion. **A big campaign is planned without knowing what it will cost.** - Estimates from a previous campaign's consumption → The decision is taken with a figure of your own. **One department spends far more than the rest.** - Checks consumption by department → The conversation happens with the right people. --- --- id: KB-IN-005 url: https://app.codecontract.io/help/integrations/automatic-notifications-to-your-system idioma: en categoria: integraciones audiencia: desarrollador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-IN-003, KB-IN-020] citadoPor: [KB-IN-007, KB-IN-008, KB-IN-009] --- # Letting your system find out by itself _Receiving a notification when something happens, instead of polling every five minutes._ **Responde a:** webhooks to receive events · notify my erp when someone signs · real-time integration · available api events Polling every few minutes to ask whether anything happened works, scales badly and arrives late. Having the platform notify your system at the moment is cheaper and faster, in exchange for an endpoint you have to get right. ## What it is used for, in practice | Event | What it usually triggers on your side | | --- | --- | | A case completes | Mark the supplier as cleared | | Someone signs | Attach the contract to the client record | | A document expires | Block the haulier at the bay | | A delivery is rejected | Open a task for whoever owns that account | ## Three things to get right 1. **Respond fast, then work** — Acknowledge receipt and process afterwards. A slow endpoint causes retries. 2. **Tolerate repeats** — The same event may arrive twice. Process by identifier, not by arrival order. 3. **Check it came from us** — Verify the notification signature. A public endpoint that believes whatever reaches it is an open door. > [!IMPORTANT] > Never process a notification without verifying its signature. It is a public URL: anyone can send it something that looks like "this contract is signed", and acting on that unchecked is exactly the hole being looked for. > [!WARNING] > An endpoint that errors on everything generates endless retries and noise. If something fails on your side, acknowledge receipt and queue the problem rather than rejecting the notification. > [!NOTE] > Most setups end with two integrations: the API to launch things and notifications to find out. They cover different directions and do not compete. **Can it be tested without touching production?** Yes, against the test environment. **What if my system is down?** Delivery is retried for a while; review the failures. **Can I choose which events to receive?** Yes, and you should: subscribing to everything fills the log with noise. ## Ejemplos **An ERP needs to know when a subcontractor is cleared for site access.** - Subscribes to the case-completed event - Verifies each notification's signature - Marks the subcontractor in its own system → The gate stops phoning the office to ask who may enter. **The ERP does not learn that a supplier completed their file and purchasing keeps blocking orders.** - Configures the automatic notification on file completion - The ERP marks the supplier as approved on receiving it → The order unblocks the same day the supplier delivers, with nobody checking anything. **Somebody logs in every morning to see whether anything changed.** - Receives a notification only when what matters changes → The daily check disappears and the notice arrives when there is something to do. **Notifications arrive about everything and the receiving system saturates.** - Subscribes only to the events that will be used → The system receives what it knows how to process. **A notification fails and nobody knows it was lost.** - Checks the delivery log and the retries → The lost notification is reprocessed rather than vanishing. **The receiving system is down an hour and ten notifications are lost.** - Configures retries and checks what is pending → The outage does not leave a hole in the data. --- --- id: KB-IN-006 url: https://app.codecontract.io/help/integrations/do-i-need-an-integration-or-not idioma: en categoria: integraciones audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-CF-006] citadoPor: [KB-IN-011, KB-IN-017] --- # Do you actually need an integration? _The question worth asking before calling in a developer._ **Responde a:** do i need to integrate code contract with my system · do i need a developer to use it · can i use it without any coding · when is an integration worth it The answer, nearly always, is no. The platform is used entirely from the screen, without writing a line of code. Integrating exists to stop typing the same thing twice, and that only pays off when that twice happens many times. ## When you do NOT need it - You are starting out. Integrating before you know how you will work is building on a process that will change. - You handle few cases a month. Typing twenty onboardings costs less than maintaining an integration. - What you want is documents in one place: for that, just use it. ## When you do | Signal | What to integrate | | --- | --- | | Someone copies the same data between systems daily | The API, to launch processes from your system | | You often ask "have they signed yet?" to update something else | Automatic notifications | | People work in a shared folder and will not give it up | Connected folder | > [!IMPORTANT] > Integrating costs technical time and has to be maintained when things change. It is a cost decision, not a requirement for using the platform: plenty of people never integrate and do fine. > [!NOTE] > The practical rule: if you cannot name the specific person losing time today typing the same thing twice, it is not time to integrate. **Can I start without integrating and do it later?** Yes, and that is recommended. **Do I need an integration for third parties to sign?** No. They never need anything. **Do I need a developer on staff?** To integrate, someone who can code. To use it, no. ## Ejemplos **A company delays starting for six months waiting to integrate with its ERP.** - Starts using it from the screen - Integrates a year later, once it knows which processes are stable → Gains six months of use, and the integration it eventually builds is smaller than it would have been. **Integration is requested before the platform has been used on a real case.** - Works a few months without integrating and notes what gets typed twice → The integration is built on a measured problem rather than an assumed one. **A process that runs three times a year is put forward for integration.** - Counts the hours saved against the cost of maintaining it → Effort goes where there is genuine repetition. **What is actually needed is a monthly export of a list.** - Uses the export instead of an integration → The problem is solved with nothing to maintain. **IT says yes to everything without knowing the scope.** - Brings the specific flow and the fields needed → The conversation happens on something bounded. **It is integrated and six months later nobody uses the flow.** - Reviews which integrations have activity → What adds nothing gets switched off and what works stays. --- --- id: KB-IN-007 url: https://app.codecontract.io/help/integrations/keeping-two-systems-in-sync idioma: en categoria: integraciones audiencia: desarrollador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-IN-005] citadoPor: [KB-IN-008] --- # Keeping two systems in sync _Which one wins when both hold the same value and they disagree._ **Responde a:** sync with erp duplicate data · which system owns a field · data does not match between systems · avoid duplicates when integrating As soon as two systems store the same value, at some point they stop matching. That is not an integration fault: it always happens. What decides whether it hurts is having agreed beforehand which of the two owns each thing. ## The rule: one owner per field Not "the ERP wins" or "the platform wins", but field by field. Each value has one place where it is edited, and the other only copies it. | Value | Usual owner | Why | | --- | --- | --- | | Supplier tax details | Your ERP | It is where invoicing happens | | Documentation status | The platform | It is where it arrives and gets approved | | Contact for paperwork | The platform | It receives the notices and shows whether they bounce | | Whether the supplier is active | Your ERP | It is a commercial decision, not a documentary one | > [!IMPORTANT] > Write that table before coding anything, even if it is four rows in a document. Integrations that become a problem do not fail technically: they fail because nobody agreed who owns what, and end up overwriting each other in a loop. ## What prevents duplicates **En corto** - Your own identifier on every contact, from day one. - Search by that identifier before creating, always. - Do not create records from both sides at once. > [!WARNING] > If your system creates a supplier whenever it cannot find one by name, you will end up with "Muñoz Engineering", "Muñoz Engineering Ltd" and "MUÑOZ ENGINEERING". Searching by identifier rather than name is what prevents it. > [!NOTE] > Start by syncing one way only. Bidirectional is where loops appear, and it is rarely needed at the start. **What if both change at once?** The field's owner wins. Which is why it has to be defined first. **Can I sync only some suppliers?** Yes, and it is a good way to test. **How do I spot they have drifted apart?** By comparing on the identifier occasionally. Without one, you cannot. ## Ejemplos **An integration creates duplicate suppliers whenever the name arrives with a different comma.** - Adds the tax identifier as the lookup key - Searches on it before creating → Duplicates stop appearing and the 40 already there are merged without losing history. **The supplier record is edited here and in the ERP, and each system holds a different version.** - Decides which one is authoritative for each field - The other system receives the change rather than editing it → There stop being two truths and nobody has to guess which one counts. **Both systems are edited at once and the last write wins silently.** - Locks editing where that field is not authoritative → The change is made in one place and propagates. **The sync goes down over a weekend and nobody notices until Tuesday.** - Sets an alert if activity stops arriving → The drift is caught in hours. **Everything is synchronised when only four fields were needed.** - Limits the sync to what is used → There is less to maintain and less to break. **A field changes format in the ERP and the sync starts failing.** - Validates the format before writing - Returns the error to whoever generated it → The fault is fixed at source rather than carried along. --- --- id: KB-IN-008 url: https://app.codecontract.io/help/integrations/what-to-do-when-the-integration-fails idioma: en categoria: integraciones audiencia: desarrollador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-005, KB-IN-007] citadoPor: [KB-IN-016, KB-IN-018, KB-IN-019, KB-IN-020, KB-IN-009] --- # When the integration stops working _How to find out before the user does, and what to check first._ **Responde a:** the integration stopped working · webhooks are not arriving · api errors in production · monitoring an integration A broken integration almost never announces itself. Everything looks fine until someone asks why a supplier is missing from the ERP, and by then it has been failing for two weeks. ## The four causes, by frequency | Cause | How to spot it | Fix | | --- | --- | --- | | Key revoked or expired | Everything fails at once with an auth error | Rotate the key and update it | | Your endpoint returns an error | Notifications retry and pile up | Check your logs, not ours | | A field changed shape | Only one kind of operation fails | Compare what is sent against what is expected | | Nobody watches the failures | Everything looks fine and half is missing | Alert on the failed queue | > [!IMPORTANT] > The fourth does the most damage and is the only one that raises no error: if nobody watches failed notifications, the integration looks healthy while losing half the events. Alert on that queue before anything else. ## The minimum to find out in time **En corto** - An alert if the failed queue rises above zero. - A log on your side of what was received and what was done with it. - A simple counter: events per day, alerting if it drops to zero. > [!WARNING] > Do not retry in an unbounded loop. An endpoint erroring on everything plus a sender retrying indefinitely produces days of noise and hides the real fault. **Can lost events be resent?** Retries have a window. Past it, reconcile by querying the API. **How do I test without touching production?** Against the test environment, with its own key. **Should I alert on every failure?** No: alert on the pattern, not the single event, or you will stop reading alerts. ## Ejemplos **An ERP has received no notifications for two weeks and nobody noticed.** - Finds its endpoint has been erroring since a deployment - Adds an alert on the failed queue → The next failure is caught in hours instead of weeks. **The integration has been down five days and it is discovered because a file is missing.** - Sets an alert if activity stops arriving - Reviews the call log weekly → The break is caught in hours rather than when somebody misses something. **It fails and nobody knows whether the problem is on one side or the other.** - Checks the call log with its error code → Diagnosis starts where it should look. **It is retried by hand and files get duplicated.** - Checks what arrived before reprocessing → The retry does not create what already existed. **The key expired and nobody knew.** - Records key expiries with a warning → Rotation happens before it cuts the service. **It is fixed and no record remains of what happened.** - Records the cause and what was done → Next time it is resolved in minutes. --- --- id: KB-IN-011 url: https://app.codecontract.io/help/integrations/what-to-ask-your-it-team-before-integrating idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-006, KB-IN-002, KB-IN-017] citadoPor: [KB-IN-012, KB-IN-013, KB-IN-019] --- # What to ask your IT team before integrating _Five questions that save three months of meetings and an integration nobody uses._ **Responde a:** preparing an integration with our erp · what do i need to integrate two systems · meeting it before an integration · integration readiness checklist Most integrations that fail do not fail for technical reasons: they fail because nobody agreed beforehand what gets synced, in which direction, and who wins when the two systems disagree. That is settled in a half-hour conversation, not in code. ## The five questions 1. **Which data exactly, and in which direction?** — "Sync suppliers" is not an answer. "Tax ID, name and document status, from here to the ERP" is. 2. **Who wins if both change?** — The question almost nobody asks and the one behind every later mess. 3. **How often?** — Instantly, hourly or nightly. It changes the work and the cost. 4. **What happens when it fails?** — Because one day it will. Who finds out and what they do meanwhile. 5. **Who maintains it a year from now?** — If the answer is "whoever built it" and that person could leave, you have an open problem. > [!IMPORTANT] > The second is decisive. Without a clear rule on who wins, the first time the systems disagree someone will fix it by hand in both places, and from then on nobody trusts either. ## What to bring to that meeting | Bring | What for | | --- | --- | | The concrete case, not "integrate" | An integration without a use case never finishes | | Who suffers the manual work today | They will know whether the result is any good | | How much time is lost now | The only way to know whether it pays | | And the option of not integrating | Sometimes a monthly file export is enough | > [!WARNING] > The last row is not rhetorical. Many integrations are proposed to save work that happens twice a month; maintenance costs more than that work. Check before you start, not after. ## The three approaches, by effort **En corto** - Notifications to your system when something happens: fastest to set up. - Queries from your system when it needs the data: fine-grained control. - Two-way synchronisation: the most powerful and the most demanding. > [!NOTE] > Starting with the first and seeing whether it suffices is almost always the right call. You can extend later; unwinding a badly designed two-way sync is far more expensive. **Do we need a developer?** For the first, barely. For the third, yes and on an ongoing basis. **How long does it take?** The technical part, days. Agreeing what gets synced, as long as you take to decide. **What if we have no IT team?** Then manual export and import is probably the right answer. ## Ejemplos **A company wants two-way supplier sync with its ERP.** - Answers the five questions and finds it only needs document status flowing to the ERP - Sets up one-way notifications → It ships in days instead of months, and maintenance does not hinge on one person. **Integration is requested without knowing which fields are needed.** - Brings the specific flow and the field list - States what triggers what and how often → IT estimates on data rather than on an intention. **IT asks about the upgrade calendar and nobody has checked it.** - Checks when each system changes before starting → The integration is not born obsolete. **It is built and nobody knows who maintains it.** - Names an owner and a deputy from the start → The integration is not orphaned. **There is no test environment and testing happens in production.** - Asks for a separate environment for testing → Go-live does not pollute real data. **Who does what is agreed verbally.** - Writes the split down before starting → Later doubts are settled by reading. --- --- id: KB-IN-012 url: https://app.codecontract.io/help/integrations/what-data-leaves-when-you-integrate idioma: en categoria: integraciones audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-003, KB-IN-011] citadoPor: [KB-IN-015] --- # What data leaves when you integrate _An integration opens a door. Worth knowing what fits through before opening it._ **Responde a:** what data does an integration share · security of an integration with another system · limiting what an access key can read · risks of connecting two platforms An integration is not just a convenience: it is a route by which information leaves here and enters somewhere else with its own rules, its own access controls and its own backups. Decide deliberately what goes through it. ## The three questions before connecting 1. **What can that connection read?** — The minimum its case needs, not everything for convenience. 2. **Where does what leaves end up?** — If the other system is in another country or run by a third party, your obligations change. 3. **Who can use that key?** — A key circulating in a team chat is no longer a key. > [!IMPORTANT] > The second is most often forgotten and has consequences beyond the technical. Personal data leaving for another system remains your responsibility, even if the problem happens there. ## What is better left in | Data | Why | | --- | --- | | Full documents, when status suffices | Almost no ERP needs the PDF: it needs to know whether it is current | | Personal data the other system does not use | If it does not use it, it only adds risk | | The whole history, when only live matters | Closed material is rarely consulted from outside | > [!WARNING] > The first row prevents half of all integration problems. "This supplier is current / is missing insurance" is a sentence; sending the insurance PDF is exporting documentation to a system that may not protect it the same way. ## How to look after an access key **En corto** - One key per integration, not one shared for everything. - With the lowest permission that works. - Stored where passwords are stored, not in a document or a chat. - And revocable in a minute, knowing who was using it. That last point is what you need on the bad day. If you do not know which integration uses which key, revoking as a precaution breaks something and nobody knows what. > [!NOTE] > Everything an integration does lands in the activity log just like what a person does. If something leaves here, you can find out when and by which route. **Can it be limited to read-only?** Yes, and for most cases that is the right choice. **What if the other platform's vendor changes?** Revoke and issue a new key; hence one per integration. **Do we need a contract with the other vendor?** If they will process your personal data, yes. Not optional. ## Ejemplos **A company wants to dump all supplier documentation into its ERP.** - Sends only document status and expiry date - Issues a read-only key for that integration → The ERP shows what purchasing needs and no document leaves the platform. **Integration goes live and more data leaves than was needed.** - Limits the integration to the fields that get used → What travels is only what is necessary. **A client asks what data of theirs goes to another system.** - Checks which fields the integration includes → The answer is specific and verifiable. **Personal data leaves without anyone deciding it.** - Reviews the content with the adviser before enabling → The decision is taken beforehand rather than after. **The data lands in a system with weaker access control.** - Checks who will see that data on the other side → Protection does not drop along the way. **Nobody knows what went out last month.** - Checks the call log → What was sent is auditable. --- --- id: KB-IN-013 url: https://app.codecontract.io/help/integrations/getting-your-data-out-for-another-system idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-009, KB-IN-011, KB-IN-009] citadoPor: [KB-IN-017] --- # Getting your data out for another system _For a report, for your ERP, or to leave. What can be taken out and in what form._ **Responde a:** exporting platform data · getting information into a spreadsheet · migrating documentation to another system · downloading everything of ours Getting information out is needed more often than expected, and not only to leave: for a report someone wants in a spreadsheet, to feed another system, to hand a file to a client, or to answer a formal request. ## Three different things asked for as if they were one | What is asked for | What it really is | When it is used | | --- | --- | --- | | "A spreadsheet with the data" | A listing: who, what, when, status | Reports and analysis | | "The documents" | The original files, with their organisation | Handovers, formal requests, system change | | "Everything" | Both, plus the activity history | An orderly exit or a deep audit | > [!IMPORTANT] > Confusing the first two causes half the disappointments. A listing without the files is useless for handing over a file; files without the listing arrive without context and the recipient cannot tell what anything is. ## What to check when exporting 1. **That filenames still say something** — A dump of files with internal names is technically complete and useless in practice. 2. **That the index of what everything is comes with it** — It is what allows rebuilding the organisation at the destination. 3. **That extracted values come separately** — Dates, amounts and identifiers in a listing, not only inside the PDFs. 4. **And that the activity history is included if needed** — For an audit or litigation, it is usually the most important part. > [!WARNING] > If the destination is another system, do not export everything on day one. Take a small sample, check it loads properly, and only then the rest. A full migration that has to be repeated costs double and is usually discovered late. ## When the export is to leave **En corto** - It can be done, and it is worth checking before you need it, not when you are already on the way out. - What is signed and sealed still verifies afterwards, even when you are no longer customers. - And what you take should include the history, not only the files. That early check is also a criterion for choosing any platform: if you cannot leave with your own material, it is not a tool, it is a dependency. > [!NOTE] > For one-off reports the listing is usually enough. Save the full export for when it is genuinely needed: it is heavier and adds nothing to an analysis. **Can only some files be exported?** Yes, and for client handovers that is the norm. **Does it include what I deleted?** No; deleted material does not return via an export. **What about personal data?** It comes out with the rest: on export, responsibility for safeguarding it moves wherever you put it. ## Ejemplos **A company asks for "an export" for a report and receives thousands of files.** - Distinguishes listing from documents and asks only for the listing → Gets the analysis in a spreadsheet in minutes, with nothing heavy to download. **A monthly list is needed and an integration is built.** - Uses the scheduled export → The problem is solved with nothing to maintain. **The export comes out without each document's context.** - Checks it includes which file it belongs to → What is exported is usable in the other system. **Everything is exported each time and the file is unmanageable.** - Exports only the period or filter needed → The file can be processed. **The export is run by hand on the 1st of every month.** - Schedules the export → The 1st stops occupying anyone. **It is exported and there is no record of what or when.** - Records the export with its date and scope → What went out is auditable. --- --- id: KB-IN-014 url: https://app.codecontract.io/help/integrations/sending-from-your-own-domain idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-004, KB-CC-011, KB-IN-010] citadoPor: [KB-IN-009] --- # Sending from your own domain _So emails go out as yours, not from a platform the recipient has never heard of._ **Responde a:** send emails from our own domain · configure dkim spf dmarc for sending · emails arrive from a sender that is not ours · verify a domain to improve deliverability When you ask a third party for documents, half the battle is getting them to open the email. And an email from a sender they do not recognise competes with the reasonable instinct to ignore it. Configuring your own domain changes exactly that: the recipient sees your name, not a tool's. ## The two ways, and how they differ | Way | What it needs | What you gain | | --- | --- | --- | | Verified domain | Three DNS records: DKIM, SPF and DMARC | Best delivery: the email is signed with your domain | | Verified address | Confirming an address of yours, no DNS | It goes from your address, but signed by the provider | | Neither | Nothing | It goes from the platform sender | > [!IMPORTANT] > The difference between the first two is not convenience, it is deliverability. With a verified domain, the email's technical signature matches your domain and receiving filters treat it as yours. A verified address without DNS is quicker to set up, but that signature does not match, and at volume or with strict filters it delivers worse. ## What to ask whoever manages your DNS 1. **To add the three records you are given** — They are TXT records and do not affect your current email: they add, they do not replace. 2. **Not to touch an existing DMARC without looking** — If you already have one it gets adjusted; replacing it can affect all your corporate email. 3. **To tell you when they are published** — Checking is automatic, but DNS takes a while to propagate. 4. **And to write it down** — Two years from now, whoever looks at those records must know what they are for. > [!WARNING] > The nuance nobody can deduce: if a send using your own sender fails — because the domain stopped being verified, the address was revoked, or the provider rejects it — the platform **retries once using the platform sender** so the email still goes out. That is the right behaviour, but it means a recipient may occasionally get a message from a different sender than you expected. If you see that, it is not a sending failure: it means your own sender is not working and needs checking. ## What stays the same when you change sender **En corto** - The cost: a send is one action, whether it goes from your domain or not. - The record: who received what and when is stored identically. - And the recipient's link: still no account and no password needed. > [!NOTE] > If you work with several brands or entities, each organisation has its own sender. You do not have to pick one for the whole group. **Does it stop emails going to spam?** It helps considerably, especially with recipients who already know you by that domain. **Can I use my usual email as the sender?** You can verify an address of yours; the full domain delivers better. **What if the recipient replies?** Set the reply address you want; otherwise replies can land in a mailbox nobody watches. ## Ejemplos **A company sends document requests and many suppliers say nothing arrives.** - Verifies its domain with the three DNS records - Checks the own sender works before the annual campaign → Emails arrive as theirs and first-send response rates rise without changing a word of the text. **Notices go out from a sender suppliers do not recognise.** - Configures sending from your own domain - Verifies with a test send before the first round → Open rates rise from the first send. **It is half configured and emails go to junk.** - Completes the records your IT asks for → The email reaches the main inbox. **The domain changes and sends start bouncing.** - Updates the configuration before the change → The domain change does not cut the campaigns. **Suppliers reply to the sender and nobody reads that mailbox.** - Configures a monitored reply address → Replies reach somebody. **Nobody checks how the notice looks on arrival.** - Sends one to themselves from outside → What looks wrong is fixed before the round. --- --- id: KB-IN-015 url: https://app.codecontract.io/help/integrations/mirroring-documents-to-your-own-folder idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-IN-012] citadoPor: [KB-IN-001] --- # Mirroring documents to your own folder _Also having in SharePoint or Drive what comes in here, without ending up with two archives that disagree._ **Responde a:** sync documents with sharepoint · copy files to google drive · also keep documents in our own folder · mirror documents to onedrive Many companies want what comes in here to appear in their corporate folder too: because some people work there, because their backups run through it, or simply because they have used that structure for years. It can be done, and it pays to understand exactly what it does and does not do. ## What the mirror does | Aspect | How it works | | --- | --- | | Direction | One way only: from here to your folder | | Structure | It reproduces the hierarchy: folder, process and document | | Versions | If the document is already mirrored, it updates that same file rather than creating another | | When | Immediately, daily or weekly, as you choose | | Scope | Everything, or only the modules you specify | > [!IMPORTANT] > The first row must be crystal clear before setting it up: **it goes one way**. A document someone drops into the SharePoint folder **does not come in here**. If your team starts saving things there assuming they sync, you will have two archives that look alike and disagree, which is worse than having one. ## When it is worth it and when not **En corto** - Worth it if some people only work in the corporate folder and will not come in here. - Worth it if your backup policy requires everything to pass through your own storage. - Not worth it "just in case": it duplicates without solving anything and costs consumption. - And it does not replace exporting: taking everything away has its own route. ## What to decide before switching it on 1. **What gets copied** — Everything or one module. Copying what nobody will look at only fills the folder. 2. **How often** — Immediately if someone needs it now; daily or weekly if it is for archiving. 3. **Who wins if something changes in both places** — This platform does, because the copy does not come back. Say it out loud to the team. 4. **And what happens to older material** — The mirror starts when you switch it on; anything earlier is moved separately if needed. > [!WARNING] > A detail you only discover once it is running: SharePoint does not accept certain characters in names (`\ / : * ? " < > | # %`), so they are replaced with spaces when copying. The file is the same, but **the name in your folder may not be identical to the one here** — worth knowing if you search there by exact name. > [!NOTE] > Each replication is an action and consumes: one per sync request. With "immediate" frequency and high volume, that shows in the breakdown — which is the argument for daily or weekly when the copy is for archiving rather than working. **Can I work in the copy?** You can open it, but what you do there does not come back. The original lives here. **What if I delete something in the corporate folder?** It is not deleted here. They are two separate places with the same content. **Does it count as a backup?** As an additional copy yes; as a recovery plan, review it with whoever owns your policy. ## Ejemplos **A company switches on the SharePoint mirror and its team starts leaving documents there.** - Explains to the team that the mirror is one way - Makes clear new material comes in here and the folder is read-only in practice → Documents that exist in the corporate folder but not in the file stop appearing. **A copy of everything is wanted in the corporate folder and it is done by hand.** - Configures the automatic copy on approval → The folder maintains itself. **Everything is copied and the folder grows without criteria.** - Copies only what is approved or final → The folder stays usable. **The copy loses the context of which file it belongs to.** - Reproduces the file structure when copying → It is found equally well in both places. **The copy is edited and stops matching the original.** - Treats the copy as an archive, not a workplace → The original remains the reference. **The copy fails for a week and nobody notices.** - Sets an alert if copying stops → The gap is caught before it is needed. --- --- id: KB-IN-016 url: https://app.codecontract.io/help/integrations/when-you-change-erp-or-provider idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-008, KB-IN-003] citadoPor: [KB-IN-020] --- # When you change ERP or provider _What breaks without warning the day another system changes, and in what order to check it._ **Responde a:** we are changing erp what happens to the integration · migrating systems without breaking connections · changing email provider integrations · reviewing integrations after a migration Integrations are built once and forgotten, which is exactly what you want from them. The problem appears when **the other side** changes: a new ERP, a different email provider, a domain migration. Nobody tells the integration, and it fails silently. ## What breaks and how you notice | Change on your side | What stops working | How you notice | | --- | --- | --- | | New ERP | Notifications keep going to an endpoint that no longer listens | You do not: that is why you must look | | Different email provider | Your own sender stops being verified | Emails start going out from the platform sender | | Domain change | Sending DNS records and custom-domain QRs | Worse deliverability, sometimes broken links | | Key rotation | Integrations using the previous key | Clear failures, and the easiest of all | > [!IMPORTANT] > The first row is the dangerous one because it **fails upstream**: the platform keeps sending correctly and it is the destination that no longer picks it up. From here everything looks fine; the gap only appears when someone misses a value in the ERP, weeks later. If you change the receiving system, that integration is reviewed the same day, not when someone complains. ## The order to review them 1. **List what integrations exist and what for** — If nobody can enumerate them, that is the first problem, not the ERP change. 2. **Start with those going outward** — They are the ones that fail without noise. 3. **Check sender and domain** — Verifications and DNS records survive migrations badly. 4. **And revoke the old system's keys** — A key for an ERP you no longer run is a live access with no owner. > [!WARNING] > Step four is always forgotten and is the most awkward in an audit: keys issued for a system the company no longer has, still active years later. It is not a theoretical risk — it is an access nobody is watching because nobody remembers it exists. ## What to leave in place for next time **En corto** - One key per integration, so you can revoke without breaking the rest. - A note of which integration uses which key and who requested it. - And a review whenever a connected system changes, not annually. The "not annually" matters: integrations do not degrade with time, they break with changes. The right trigger is the change, not the calendar. > [!NOTE] > If the integration was built by an outside firm you no longer work with, review it anyway: what you need to know is not how it was made, but what keeps going out and with which credential. **How do I know an integration still works?** By what arrives on the other side: if the destination does not pick it up, you cannot see it here. **What if the new ERP does not support the same thing?** Go back to which data and in which direction: it is nearly always less than what was built. **Do we have to redo the custom sender?** If the email provider or the domain changes, yes: verification belongs to that domain. ## Ejemplos **A company migrates ERP and three months later misses data it believed was syncing.** - Reviews outbound integrations on the day of the change - Revokes the old system's keys → The three-month gap does not recur and a live ownerless access disappears. **The ERP changes and the integration stops working the same day.** - Builds the new integration before switching the old one off - Verifies with real cases during the overlap → The ERP change does not cut the flow of files. **Nobody knows which fields the previous integration fed.** - Documents the flow before dismantling it → The new integration covers the same ground. **The old system is switched off with unprocessed notifications.** - Checks what is pending before switching off → Nothing is lost along the way. **The new provider promises the same and does not deliver.** - Tests the real flow before signing → The promise is verified before you depend on it. **The old system's key stays active months later.** - Revokes the keys on dismantling → Access does not stay open. --- --- id: KB-IN-017 url: https://app.codecontract.io/help/integrations/integrating-without-programming idioma: en categoria: integraciones audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-006, KB-IN-013, KB-IN-019] citadoPor: [KB-IN-011] --- # Integrating without programming _Manual export and import, done properly, solves more cases than people think and depends on nobody._ **Responde a:** integrate without a developer · export to spreadsheet monthly · we have no it team how do we connect · alternative to an integration When connecting two systems comes up, the conversation jumps straight to the technical. And for a large share of real cases — a company needing its data to reach its accountants, its ERP or a spreadsheet once a month — the answer that works requires no programming at all. ## When this is enough | Situation | Integration needed? | Why | | --- | --- | --- | | A monthly report for the accountants | No | An exported listing does exactly that | | Feeding a dashboard | No, if it updates weekly | Frequency decides, not the tool | | Blocking an order if documents are missing | Yes | It needs both systems talking in the moment | | Showing document status in the ERP | It depends how soon it must be useful | Next day is usually fine | > [!IMPORTANT] > The third row marks the real boundary: **integration is needed when something must happen in the moment**. Everything else — reports, analysis, feeding another system, reviewing — tolerates hours or days of lag, and there a file exported weekly does the job without depending on anyone or breaking when the other system changes. ## How to do it properly, which is what makes the difference 1. **A fixed date and a named owner** — "First Monday" and a person. Without that, it runs three months and gets abandoned. 2. **Always the same format and the same columns** — It is what lets the recipient process it the same way every time. 3. **With the period stated in the file itself** — A listing with no period generates a query every month. 4. **And keep what was sent, not only send it** — It is the difference between explaining a discrepancy and arguing about it. > [!WARNING] > What turns this into a problem is double entry: exporting from here, adjusting by hand and loading into the other system **changing things along the way**. From then on there are two truths and neither governs. If data needs correcting when it moves, the place to correct it is the source, not the copy. ## What you gain over an integration **En corto** - It depends on nobody: if that person is away, someone else does it identically. - It does not break when the other system changes version. - You can start tomorrow, with no project and no budget. - And if it eventually falls short, you know exactly what to automate. That last point is the most valuable: six months of doing it by hand tell you which data you actually use and how often. Many integrations are designed to move things nobody ever looks at. > [!NOTE] > Exporting a listing is not one of the consuming actions; what may consume is generating a report. A monthly file does not move the consumption needle, which is another reason to start here before building anything. **Is an integration not more professional?** Solving the problem is more professional. Many integrations are built to save ten minutes a month. **What if the other system will not take the format?** Nearly all accept a spreadsheet; if not, that is the genuine technical conversation. **When do we move to integrating?** When the lag genuinely bothers you, not when someone proposes it. ## Ejemplos **A company quotes an ERP integration and shelves it on cost.** - Sets up a monthly listing with a fixed date and an owner - Six months later it knows which two values it actually uses → When it does integrate, it integrates only those — and the project costs a fraction of the quote. **Two tools need connecting and there is nobody to write code.** - Uses the available no-code connections → The flow is built without depending on development. **The no-code connection is built and nobody documents it.** - Notes what triggers what and who maintains it → The connection is not orphaned. **A flow is built that does more than intended.** - Starts with one step and adds afterwards → The behaviour is understood at each step. **It fails and nobody knows where to look.** - Checks the run history → Diagnosis starts where it should look. **It is built with the personal account of whoever made it.** - Uses a company service account → The connection outlives that person's departure. --- --- id: KB-IN-018 url: https://app.codecontract.io/help/integrations/when-whoever-built-the-integration-leaves idioma: en categoria: integraciones audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-003, KB-IN-008] citadoPor: [KB-IN-020] --- # When whoever built the integration leaves _It does not break: it keeps running. The problem is that nobody knows what it does or dares switch it off._ **Responde a:** the developer who built the integration left · we do not know what this access key is for · can I disable an old integration · auditing access keys People fear the opposite of what happens. When whoever built the connection to your system leaves, the connection does not break — it belongs to the organisation, not to that person, and it carries on working exactly the same the next day. What leaves with them is knowing what it does. ## What stays, and what goes | What | What happens to it when that person leaves | | --- | --- | | The access key | Stays active: it belongs to the organisation | | What the integration sends and receives | Carries on unchanged, telling nobody | | Why it was created and what breaks if switched off | Leaves with whoever built it | | Where that key is copied | Usually the first thing lost | > [!IMPORTANT] > That last point is what really hurts: **an active key is worth the same wherever it is copied**. If it lived on the laptop of whoever left, in a script on their machine or in a note of theirs, it still opens the door from there. Removing that person's user is not enough: the user and the integration key are different things, and removing one does not touch the other. ## What to do in the first few days 1. **List the active keys and when each was last used** — Last used says more than its name does. 2. **Rotate any key for an integration that person touched** — Create a new one, put it in the system, retire the old one. 3. **Give each one a name and an owner** — Which system uses it and who answers for it today, not who created it. 4. **And retire whatever has not been used for months** — It is the only thing you can switch off fearlessly, because nothing calls it. > [!WARNING] > On switching off a key whose purpose you do not know: **disabling is not deleting**. If retiring it stops something working, you find out at once and step back by issuing another; the cost of being wrong is an afternoon, not lost data. The alternative — leaving it active just in case, forever — is the one that ends in an unanswered client questionnaire. ## How not to end up here again **En corto** - One key per integration, never one shared across several. - With an expiry set from the start: it forces a review and someone to claim it. - And only the permissions needed: if it only has to read, it should not be able to write. > [!NOTE] > The same applies when the one leaving is an outside provider, and all the more so: the relationship ends, the key does not, and nobody is going to remind you to withdraw it. **Can I find out what an integration did?** The activity log shows what the key did, though not why it was created. **What if the system using it no longer exists?** Then it is a clear candidate: retire and wait. Nothing will call it. **Does rotating a key cut the service?** Only if you retire the old one before installing the new. Install first, retire after. ## Ejemplos **A company inherits four undocumented access keys after its developer leaves.** - Checks when each was last used, rotates the two live ones and retires the two dead ones → It ends up with two owned integrations and no doors left open from a laptop it no longer controls. **The person who built the integration leaves and nobody knows how it works.** - Documents the flow and the keys before they go - Names a new owner on their last day → The integration keeps working and there is somebody to ask. **The integration runs on their personal account.** - Migrates to a service account before the departure → Closing their account stops breaking the flow. **The keys sit on their computer.** - Stores the keys in the secret manager → Access does not leave with the laptop. **It fails two months later and nobody knows where to look.** - Documents the log and the usual failure point → Diagnosis does not start from zero. **Nobody knows which integrations exist.** - Keeps an inventory with owners → None is orphaned. --- --- id: KB-IN-019 url: https://app.codecontract.io/help/integrations/testing-an-integration-without-messing-up-real-data idioma: en categoria: integraciones audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-008, KB-IN-011] citadoPor: [KB-IN-017] --- # Testing an integration without messing up real data _What you test with real data really goes out: notices, emails and records you then have to explain._ **Responde a:** testing an integration without sending real notices · how to test without polluting data · I ran a test and an email went out · test data in production Every integration goes through a testing phase, and it is nearly always done on whatever is there: you grab a real file because it is the one with complete data. It works first time, which is why nobody notices the problem until the following week. ## What happens when you test on the real thing | What the test does | What it actually triggers | | --- | --- | | Marking a file as completed | Any notices depending on that status fire | | Creating a sample request | Someone outside receives a request nobody meant to send | | Updating a field to see if it travels | It is written into the history of something real | | Resending the notice ten times | Your system receives the same event ten times | > [!IMPORTANT] > The row that causes the most real incidents is the second: **a test notice on a real contact genuinely goes out**. The platform does not tell a test from a real send, because to it they are exactly the same act. That is the awkward call the next day — a supplier asking about a request they do not understand — and the only way to avoid it is for the recipient of any test to be you. ## How to test properly 1. **A test file, named so it says so** — «TEST — do not use», so nobody mistakes it in a listing. 2. **Test contacts using your own addresses** — If anything goes out, it reaches you. 3. **Test the notice first, the action after** — Watching the event reach your system touches nothing real. 4. **And clean up when finished, noting what it was** — Whatever stays behind ends up counting in a report. > [!WARNING] > Watch out too for what the test does not break but does pollute: **test files count in the numbers**. They show in the monthly totals, in the average days to close and in the report you show a client. That is why they are worth deleting rather than left «just in case»: nobody remembers six months later that those four September files came from an integration test. ## Before signing the integration off **En corto** - Check what happens when it fails, not only when it works: that is what will happen one day. - Cause an error deliberately and see whether anyone notices. - And write down what it does, for whoever looks at it in two years. > [!NOTE] > If your IT team needs a separate environment to test against data that is not yours, that is a conversation worth having before integrating, not halfway through testing. **Can I test with a friendly client?** Better not: the test leaves a trace in their file, not only yours. **What if I need realistic data?** Copy the shape, not the content: made-up names with the same structure. **How long should test files stay?** As long as the test. After that, out. ## Ejemplos **A company tests its integration by marking a real file as completed.** - Creates a test file with its own contacts and deliberately causes a failure → The test shows what happens when it breaks, with no supplier receiving anything odd. **Testing happens in production and twenty fake files get created.** - Tests in a separate environment - If there is none, uses data marked as test and closes it afterwards → Reports do not start out mixing tests with real records. **The tests send emails to real suppliers.** - Uses your own test contacts → Nobody outside receives an email from a trial. **The happy path is tested and it fails on the day of the error.** - Also tests what happens when the data arrives wrong → Behaviour under error is known beforehand. **Testing finishes and the data stays.** - Closes and clears the test material before opening → Go-live starts clean. **Nobody knows whether what was tested is what goes live.** - Checks the configuration is the same → What was tested is what gets deployed. --- --- id: KB-IN-020 url: https://app.codecontract.io/help/integrations/when-your-own-system-gets-updated idioma: en categoria: integraciones audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-008, KB-IN-016, KB-IN-018] citadoPor: [KB-IN-005] --- # When your own system gets updated _You do not change programs: it just gets updated. And the integration keeps working, which is exactly what makes it dangerous._ **Responde a:** the erp was updated and the integration fails · version upgrade and changed fields · the integration runs but data is missing · warning the vendor before upgrading Your IT team or your vendor updates the program over a weekend. On Monday everything works: people log in, orders go out, and the integration keeps sending data. That is why this problem takes weeks to surface, and by then it has polluted the record. ## How an integration breaks while still running | What changed | What you see | What is really happening | | --- | --- | --- | | A field was renamed | Everything looks the same | That value arrives empty and nobody looks | | A field changed format | The data comes in | It comes in wrong: different dates or amounts | | A mandatory field was added | Some sends start failing | The good case: it shows | | How a record is identified changed | Duplicates appear | Each send creates a new one instead of updating | > [!IMPORTANT] > The first two rows are dangerous for the same reason: **an integration does not warn about what it stops receiving**. If a field is renamed there is no error: there is a gap, and files keep being created with that value empty for weeks. When someone notices, you must decide whether to fill two hundred cases by hand. The noisy failure — the send that breaks — is actually the best case, because it is found the same day. ## What to do around an update 1. **Find out when it is happening, even if it «does not affect you»** — It is information that rarely reaches whoever owns the integration. 2. **Ask what changes in the data, not in the interface** — What matters to an integration is not in the release notes. 3. **Check one complete case the next day** — A real one, with its data, not a ping. 4. **And scrutinise that week's files** — That is where the gaps will show if there are any. > [!WARNING] > The check worth having in place before it happens: **one that looks at whether the value arrives, not whether the send responds**. The integration answering «received» says nothing about what was inside. A simple review — how many of the latest files have that field empty — catches in a day what otherwise surfaces when a client asks why a number is missing. ## If you are the one updating **En corto** - Tell whoever maintains each integration beforehand, not afterwards. - Keep an example of how the data arrived before the update: that is your comparison. - And if you can, update on a day when someone can look the next morning. > [!NOTE] > The same problem appears when the party at the other end updates without telling you. The difference is that you cannot plan for it — only detect it early, which is what the check above is for. **Can I test the update somewhere first?** Ask your IT team: if there is a test environment, this is when to use it. **What if the gap is weeks old?** Backfill what you can in bulk and record from when it was missing. **Should the integration be frozen during the update?** Pausing it briefly is cheaper than cleaning duplicates later. ## Ejemplos **A company updates its ERP and three weeks later finds files with no order number.** - Checks one complete case the next day and reviews how many arrive with the field empty → The gap surfaces in a day instead of across two hundred files needing review. **The ERP is upgraded over a weekend and on Monday the integration is broken.** - Asks IT for the upgrade calendar - Tests the flow in the test environment before the switch → The upgrade is faced with the integration already verified. **A field changes and the integration starts failing silently.** - Sets an alert if activity stops arriving → The fault is caught in hours. **It is upgraded and nobody tests anything.** - Tests a real case straight afterwards → The problem is found before the users find it. **The upgrade changes a data format.** - Validates the format before writing → The bad value does not propagate. **Unprocessed notifications pile up during the window.** - Checks what is pending afterwards → The window does not leave a hole. --- --- id: KB-IN-009 url: https://app.codecontract.io/help/integrations/which-events-the-platform-can-notify idioma: en categoria: integraciones audiencia: desarrollador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-005, KB-IN-008, KB-IN-014] citadoPor: [KB-IN-013] --- # The twenty events it can notify your system about _The complete catalogue of what can trigger something on your side._ **Responde a:** which events does the platform emit · available webhooks list · notify my erp when something happens · case and request events Your system can find out the moment something happens here, without polling. This is everything it can be notified about, grouped by what it happens to. ## What happens to a case | Event | When it fires | | --- | --- | | It completes | Everything mandatory is delivered and approved | | It is cancelled | Someone closes it incomplete | | It is duplicated | A new one is created from it | | A phase is added | The case grows while running | | A block is imported | Documentation arrives in bulk | | It is deleted | It ceases to exist | ## What happens to a request | Event | Typical use | | --- | --- | | It is sent | Record in your system that it was asked | | It is opened | Know it genuinely arrived | | It is answered | Trigger your next step | | It is received | Mark the document as in | | It is rejected | Open a task for whoever asked | | It is reminded | Count the chasing | | It is resent | Detect problem contacts | ## What happens to a document | Event | Typical use | | --- | --- | | It is uploaded | Reflect it in your document manager | | Data is extracted | Push those values into your system | | It is certified | Store the evidence reference | | Generated from a template | Trace automatically created documents | | Filled in manually | Tell manual from automatic | ## Approvals Approved or rejected. These two trigger the most work on the other side: approving usually unblocks something of yours, and rejecting usually opens a task. > [!IMPORTANT] > Subscribe only to what you will use. Listening to all twenty fills your log with events nobody processes, and when an important one fails it will be buried among them. > [!WARNING] > Each webhook delivery consumes a credit. Twenty events per case at high volume adds up; listening to three well-chosen ones costs a fraction and solves the same. > [!NOTE] > The three that cover most real integrations: case completed, request answered and approval decided. Those three automate nearly everything people want to automate. **Can I choose which to receive?** Yes, and you should. **What if my system is down?** Delivery is retried; check the failed queue. **Can it be tested outside production?** Yes, against the test environment. ## Ejemplos **A team subscribes to all twenty events and two weeks later nobody reads the log.** - Keeps three: case completed, request answered and approval decided → The log becomes readable again and consumption drops, without losing any automation. **All twenty notifications are subscribed and the receiving system gets constant noise.** - Subscribes only to the events that will be processed - Adds the rest when there is something to do with them → The system receives what it can use and the log stays readable. **You want to react to a document expiring and do not know which event covers it.** - Checks the list of available events → The integration is built on what exists. **A notification arrives twice because of a retry.** - Treats the notification as idempotent by its identifier → The same event does not trigger two actions. **The notification arrives and the receiving system does not know which file it refers to.** - Includes the file identifier in the handling → The action is applied where it belongs. **A flow changes and the notifications stop fitting.** - Reviews the subscriptions when the process changes → The integration keeps up with the change. --- --- id: KB-IN-010 url: https://app.codecontract.io/help/integrations/connecting-the-platform-to-your-assistant idioma: en categoria: integraciones audiencia: desarrollador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-MA-002] citadoPor: [KB-IN-014] --- # Connecting the platform to your own assistant _Letting an AI assistant of yours query and act on your cases._ **Responde a:** connect claude or chatgpt to the platform · mcp assistant integration · query cases from my assistant · give an external ai access If your team already works with an AI assistant, it can query your cases directly instead of someone copying and pasting what is inside. It is a connection that is authorised and scoped, not open access. ## The three access levels | Level | What it allows | When to use it | | --- | --- | --- | | Read only | Query and answer questions about what is there | Nearly always. It solves 90% of cases | | Read and write | Also create and modify | When the assistant has to leave work done | | Full | All of the above without restriction | Rarely, and with a very good reason | > [!IMPORTANT] > Start with read-only and stay there if it serves you. An assistant that can write can make mistakes writing, and what it does is recorded in the name of the organisation that authorised the connection — yours. ## What it genuinely solves **En corto** - Asking about case status without opening the platform. - Cross-referencing what is here with what you hold elsewhere. - Preparing answers to customer questionnaires with real data. > [!WARNING] > The connection inherits permissions: the assistant sees no more than the account that authorised it. If that account is an administrator's, the assistant sees everything. Authorise it with a scoped account, not your most privileged one. > [!NOTE] > Every query the assistant makes consumes, exactly as if a person made it. An assistant querying in a loop spends in a loop: check the breakdown in the first week. ## Before connecting Decide which assistant, with which account and at what level. Those three answers written down somewhere avoid the conversation a year from now about who authorised what. **Can I revoke it?** Yes, at any time. **Is what it queries recorded?** Yes, like any access to data. **Does it see other organisations' documents?** No. Nothing crosses the separation between organisations. ## Ejemplos **A team authorises the connection with an administrator account to move fast.** - Redoes it with a scoped, read-only account → The assistant still answers what they needed and can no longer see payroll. **The team wants to query files from their own internal assistant.** - Connects the assistant through the supported route - Limits the scope to the files that account can see → Queries happen where people already work, and the assistant sees no more than the person would. **The in-house assistant returns data from other files.** - Reviews which permissions it is connected with → The assistant's scope is the account's, not the company's. **It is connected and nobody knows what it queries.** - Checks the assistant's call log → Usage is auditable like any other access. **The assistant asserts things that are not in the documents.** - Checks which files the answers come from → Claims can be cross-checked. **An assistant answer is shared with a client.** - Reviews the text and its source before sending → What goes out carries your judgement. --- --- id: KB-IN-001 url: https://app.codecontract.io/help/integrations/connecting-to-your-systems idioma: en categoria: integraciones audiencia: desarrollador actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-001, KB-TZ-001, KB-CR-002, KB-IN-015] citadoPor: [KB-IN-002] enLaApp: https://app.codecontract.io/settings/api-keys --- # Connecting the platform to your systems _API, webhooks and external storage: what to choose depending on what you automate._ **Responde a:** code contract api · integrate with my erp · webhooks to receive platform events · sync documents with sharepoint · create an api key There are three ways to connect the platform to what you already run, and you pick by the direction you want data to flow. Confusing them is the usual reason an integration ends up polling every five minutes for something that could have been pushed to it. **En corto** - API: you ask for things or create them from your system. - Webhooks: the platform tells you when something happens, without you asking. - External storage: documents are replicated into your own repository. - An API key is created with just the permissions it needs, not all of them. ## Which one to use | You want | Use | Example | | --- | --- | --- | | To create something from your system | API | The ERP registers a supplier and launches the document process | | To find out something happened | Webhook | Notify your system when a contract is fully signed | | The files in your repository too | External storage | Everything certified also appears in your corporate folder | | To query occasionally | API | A monthly report reading the state of your cases | _If you find yourself polling every few minutes to see whether something changed, what you needed was a webhook._ ## API keys Created from the organisation settings, with the permissions that integration needs and no more. A key that only has to certify documents should not be able to delete contacts. And one key per integration is worth it, so you can revoke one without breaking the others. > [!IMPORTANT] > An API key grants access to your organisation's data. It must not end up in a code repository, an email or a chat message. If you suspect one has been exposed, revoke it: creating another takes a minute. ## Webhooks You provide a URL and the platform notifies you when whatever you subscribed to happens. What matters when building it is that your end responds quickly and tolerates receiving the same notice twice: any delivery system can retry, and processing it twice should not duplicate anything on your side. ## Frequently asked questions **Where is the API documentation?** On the public API documentation page, with endpoints and parameters. This article is the overview; the detail lives there. **Can I certify automatically from my ERP?** Yes, and it is one of the most frequent uses: each invoice or record is certified as it is generated, with nobody having to remember. **What if my endpoint is down when a webhook fires?** It is retried. Which is why your end should tolerate receiving the same notice more than once. **Does external storage move or copy?** It replicates: documents stay on the platform with their traceability and also appear in your repository. ## Ejemplos **A company wants every invoice issued by its ERP certified with no human involvement.** - Creates an API key with certify-only permission - The ERP calls the API at the moment the invoice is issued - Subscribes a webhook to record the evidence identifier back in the ERP → Every invoice carries a demonstrable date from the second it exists, and nobody has to remember anything. **A contractor onboards eighty subcontractors a year in their ERP and somebody retypes the same data here.** - The ERP calls the API as soon as the subcontractor is created - The documentation process launches by itself with that data - The ERP gets a notification when the file completes → Double keying disappears for eighty onboardings, and the ERP knows who may enter site without being told. **Purchasing checks two screens to know whether a supplier is current.** - Brings the file's status into the system where the order is approved - Updates that status whenever it changes here → The order is approved on the screen where people were already working. **Everything is integrated at once and two months later nobody knows what each connection does.** - Integrates the most repeated flow first - Documents what triggers what before adding the second → The second integration is built on something understood rather than a black box. **The ERP sends incomplete data and half-built files get created.** - Validates the mandatory fields before creating anything - Returns the error to whoever generated it instead of creating the file → The files that exist are complete, and the error is fixed in the system where it started. **Nobody knows whether the integration still works until a file is missing.** - Reviews the call log weekly - Sets an alert if activity stops arriving → The break is caught in hours rather than when somebody misses something. --- --- id: KB-IN-002 url: https://app.codecontract.io/help/integrations/three-ways-to-connect-your-systems idioma: en categoria: integraciones audiencia: desarrollador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-001, KB-TZ-001] citadoPor: [KB-IN-005, KB-IN-006, KB-IN-007, KB-IN-011, KB-IN-015, KB-IN-010, KB-IN-003] --- # Connecting it to your systems _The three ways to connect, and which to pick for what you need._ **Responde a:** integrate code contract with our erp · api to create processes automatically · get notified when someone signs · connect to sharepoint If you already have a system where the information lives — an ERP, a CRM, a shared folder — there are three ways to connect it. The difference is who starts the conversation. | Approach | Who starts | What it is for | | --- | --- | --- | | API | Your system | Create processes, upload documents, query status from your own code | | Automatic notifications | The platform | Learn the moment someone signed or delivered, without polling | | Connected folder | Both | Have documents appear where your people already work | ## Which to choose - If your system is in charge and wants to launch processes: API. - If what you need is to react to what happens here: automatic notifications. - If people already work in a shared folder and you do not want to change that habit: connected folder. They are not exclusive, and most setups end up with two: the API to launch and notifications to find out. > [!WARNING] > Automatic notifications must be acknowledged: if your system does not respond, delivery is retried. An endpoint that errors on everything generates endless retries and noise. ## Before writing code The technical documentation with endpoints, authentication and examples lives in the platform itself. This article is the map; the detail is there. **Is there a test environment?** Yes, so you do not dirty real data while developing. **Do access keys expire?** They can be rotated and revoked. One per integration is better than one for everything. **Does using the API consume credits?** It consumes exactly what the same action would through the screen, no more. ## Ejemplos **A construction firm wants onboarding to start automatically when a subcontractor is created in their ERP.** - The ERP calls the API when creating the subcontractor - Receives an automatic notification when the case completes - Marks the subcontractor as cleared in its own system → Nobody types anything twice, and the ERP knows who may enter site without being told. **An advisory firm with four hundred clients wants creating a client in their practice software to trigger the document request.** - Their software calls the API when the client record is created - The onboarding template launches with the data it already had - The status returns to their software when the client delivers → Onboarding stops being double work and the firm sees progress without leaving their tool. **Each department wants its own connection and four are built doing almost the same thing.** - Defines one flow and treats the special cases as variants → There is one integration to maintain instead of four that clash. **The connection is built against a version of the system that is about to change.** - Asks IT for the upgrade calendar before starting → The integration is not born obsolete. **A process that runs three times a year is integrated.** - Weighs it against doing it by hand → Effort goes where there is genuine repetition. **It is connected and not tested with real data until go-live day.** - Tests a real case in a separate environment - Checks what happens when the data arrives wrong → Go-live is not also the first test. --- --- id: KB-IN-003 url: https://app.codecontract.io/help/integrations/access-keys-and-how-to-look-after-them idioma: en categoria: integraciones audiencia: desarrollador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IN-002, KB-AD-002] citadoPor: [KB-IN-005, KB-IN-012, KB-IN-016, KB-IN-018] --- # Access keys: how not to get it wrong _One per integration, out of the code, and rotated before you have to._ **Responde a:** create an api key · i pushed a key to github what now · rotate integration credentials · revoke an api key An access key is a password no human types, and that is why it gets treated worse: it ends up in a repository, in a team chat, or in a script somebody copied. Three rules avoid nearly everything. **En corto** - One key per integration, never one shared between several. - Never in the code and never in a message. - With the minimum permission that integration needs, not all of them. ## One per integration If the ERP and the time-tracking system share a key, revoking it because one was compromised takes down the other. With one each, you revoke what is affected and move on. ## Out of the code In your system's environment variables, not in a file that gets committed. It is the commonest mistake and the worst to fix afterwards: deleting it from the code does not delete it from the history. ## If it has leaked 1. **Revoke it now** — Before investigating how it happened. A leaked key stops working the moment it is revoked. 2. **Create a new one and swap it** — In the system that was using it. 3. **Check what was done with it** — Accesses are logged. That is where you see whether anyone used it. > [!IMPORTANT] > Changing the key in the code without revoking the old one fixes nothing: the old one still works for whoever holds it. Revoking is the step that counts. > [!NOTE] > Rotating periodically even when nothing has happened turns rotation into a familiar chore rather than an emergency on the day it matters. **Do they expire on their own?** They can be given an expiry, and it is a good idea. **Can I see a key after creating it?** No. It is shown once; if lost, create another. **How many can I have?** As many as you need. Many narrow keys beat one with every permission. ## Ejemplos **A developer finds a key was left in a public repository two weeks ago.** - Revokes it immediately - Creates a new one and puts it in environment variables - Reviews the access log for those two weeks → Confirms it was never used from outside and the incident closes in twenty minutes. **The API key is shared over messaging between three people and ends up on a supplier's phone.** - Creates one key per integration, not per person - Revokes the one that circulated and issues a new one → Each connection has its own key, and revoking it breaks nothing else. **The key is hard-coded by somebody who no longer works there.** - Stores keys in the secret manager, not in code - Rotates the key when the person leaves → A developer leaving stops being a security incident. **A key grants access to everything when the integration reads two fields.** - Gives each key the minimum scope it needs → A leaked key exposes two fields rather than the whole archive. **Nobody knows which keys are active or what for.** - Checks the list and notes what each one is for → The unused ones can be withdrawn. **A key has not been rotated in three years.** - Sets a rotation schedule with advance warning → Rotation happens calmly rather than after a scare. --- --- id: KB-IN-004 url: https://app.codecontract.io/help/integrations/putting-your-brand-on-what-third-parties-see idioma: en categoria: integraciones audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-003, KB-CO-013] citadoPor: [KB-IN-014] --- # Making it look like you, not us _An email that looks like yours gets opened; one that looks like a tool does not._ **Responde a:** customise emails with my logo · use my own domain for sends · hide code contract branding · white label sends The third party you ask for documents does not know you as a customer of some platform: they know you. If the email arrives with branding they do not recognise, the reasonable first reaction is suspicion — and they are right. **En corto** - Your logo and colour in the email and on the page it opens. - Your domain as sender, which counts for most. - Nothing the recipient has to interpret. ## What you can set | Element | Effect on the recipient | Effort | | --- | --- | --- | | Logo and colour | They recognise who it is at a glance | Five minutes | | Sender on your domain | Mail lands where it should, not in spam | Ten minutes of your IT person's time | | Own domain on the link | The link does not look third-party | A little configuration | > [!IMPORTANT] > Of the three, the sender on your own domain changes the most. It is not cosmetic: an email claiming to come from you without being able to prove it is treated as suspicious by filters, correctly. ## What not to hide That the signature or the sealing is provided by a platform is not something to conceal: it is part of why the document holds. Branding is so people recognise who is writing, not to disguise how it works. > [!NOTE] > If you send to third parties who do not know you — new suppliers, a client's clients — this matters more than any improvement to the wording. **Do signers see it too?** Yes, in the email and on the page it opens. **Do I need IT help?** Only for the domain, and it is a ten-minute change. **Can branding differ per team?** It depends how your organisation is set up; ask if you operate several brands. ## Ejemplos **A company sends requests to suppliers who do not know it and half never reply.** - Adds its logo and colour - Its IT person authorises sending from the company domain → Open rates rise markedly without changing a word of the text. **A supplier receives the notice, does not recognise the sender and deletes it as suspicious.** - Configures sending from your own domain - Uses a subject naming your company and the reason → The email gets opened because the supplier recognises who is writing. **The screen the supplier sees looks nothing like your website.** - Applies your logo and colours to the external portal → The supplier proceeds confident they are in the right place. **The custom domain is half configured and emails go to junk.** - Completes the records your IT asks for - Verifies with a test send before the first round → The first campaign does not start with half of it in the bin. **Each department uses a different signature on notices.** - Unifies the communication template → The supplier receives a coherent message whoever it comes from. **Branding is configured and nobody checks how it looks on a phone.** - Sends themselves a notice and opens it on a handset → What looks wrong is fixed before anyone outside sees it. --- --- id: KB-TZ-003 url: https://app.codecontract.io/help/traceability-and-compliance/how-long-to-keep-documents idioma: en categoria: trazabilidad audiencia: administrador nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-001, KB-AD-003] citadoPor: [KB-AD-004, KB-MA-003, KB-DI-010, KB-CS-012, KB-TZ-013, KB-LE-020, KB-LE-022, KB-TZ-006, KB-GL-013] --- # How long to keep documents _Keeping too much also has a cost, and it is not storage._ **Responde a:** how long must documents be kept · data retention policy · delete old documents gdpr · obligation to retain contracts Keeping everything forever looks prudent and is not: the more personal data you keep without reason, the greater the harm if something ever goes wrong, and the less defensible holding it is. The rule is to keep what must be kept, for as long as it must be kept. **En corto** - The period follows what the document is for, not the space it takes. - Personal data with no reason to be there is a risk, not an asset. - The policy is defined once and applies itself. ## Orders of magnitude | Document type | Typically kept | | --- | --- | | Contracts and amendments | For the life of the relationship, plus the limitation period | | Tax documentation | Whatever your tax rules require | | Third parties' identity documents | The bare minimum; often verifying without storing is enough | | Signature evidence | As long as the signed document has effect | _Exact periods depend on your country and sector: this is the criterion, not the legal table._ > [!IMPORTANT] > This is not legal advice. Exact periods are set by your regulations and your adviser; what the platform does is apply what you decide, consistently and on the record. ## What happens when the period is up Whatever your policy says: deletion, or archiving without personal data. Either way there is a record that the rule was applied, which is what you need to be able to show. > [!WARNING] > If someone exercises their right to erasure, that sits alongside retention obligations: some documents must be kept by law even if the person asks for deletion. The policy is what resolves that in advance rather than case by case. **Can periods differ by type?** Yes, and that is the sensible approach. **Is there a warning before deletion?** A prior notice can be configured. **What about ongoing litigation?** Deletion of affected material is suspended. Deleting something relevant to live litigation is a serious problem. ## Ejemplos **A company has kept copies of candidates' ID documents for eight years.** - Defines that only those of people who were hired are kept - Applies the policy to the backlog → It stops holding thousands of identity documents it had no reason to hold. **Everything is kept indefinitely just in case.** - Applies a retention policy by type → What is kept has a reason and a period. **Something needed years later has been deleted.** - Sets the periods with the adviser before deleting → Deleting stops being a gamble. **Nobody knows how long each document type is kept.** - Checks the applied policy → The decision is taken once and applies itself. **A client asks how long you keep their material.** - Answers with the written policy → The answer is specific. **The archive grows without criteria.** - Reviews what has passed its period → The archive stops growing unchecked. --- --- id: KB-TZ-007 url: https://app.codecontract.io/help/traceability-and-compliance/showing-your-history-to-an-outsider idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-005, KB-CF-003] citadoPor: [KB-TZ-011, KB-TZ-021] --- # Showing your history to an outsider _An auditor, a lawyer, a client: what to give them and what not._ **Responde a:** give an auditor access to case files · show a client the history · share traceability with a third party · export the log for a lawyer The moment comes to show how you work to someone outside. The temptation is to prepare a folder of what you will show them, and that is exactly what not to do: if you made the selection, whoever is looking knows it and will ask for the rest. ## The three ways, best to worst | How | When | What it leaves | | --- | --- | --- | | Scoped read access | Audits, periodic reviews | Nothing loose, and a record of what they looked at | | Export with its dates | When they must keep it: a lawyer, a court | A file you no longer control | | Screenshots | Never, if avoidable | Something anyone could fabricate | ## What to scope before granting access - The scope: the site, client or period the review covers, and nothing else. - The time: access for the duration of the engagement, not indefinitely. - The level: read-only. Nobody outside needs to change anything. > [!IMPORTANT] > If your cases contain third parties' documents — a subcontractor's workers, a client's clients — granting broad access is not only your decision: you are showing information about people who never authorised it. Scope it to the actual review. > [!WARNING] > Do not modify or reorganise anything while a review or a claim is running. Every change is logged with its date, and a change made after it starts always reads in the worst possible way. > [!NOTE] > Scoped access usually impresses more than a prepared dossier: it shows the control genuinely exists, not that you can assemble a folder. **Is what they looked at recorded?** Yes, with date and time. **Can I remove access when it ends?** Yes, and it should be done that day. **What if they ask for something out of scope?** Grant it if appropriate, by widening the scope expressly. Broad access "just in case" is not the answer. ## Ejemplos **A large client asks to audit how documentation on their sites is controlled.** - Grants scoped read access to their three sites - For the duration of the audit → The auditor sees what they need, it is logged, and not one document from another client leaves. **The history is shown by sending screenshots.** - Shares the file with controlled access → The third party verifies rather than believes. **Too much is shared when showing a case.** - Shares only what is relevant → What was asked for is delivered, and nothing more. **There is no record of what was shown.** - Records what was shared and with whom → The handover is demonstrable afterwards. **Access stays open after the review.** - Revokes access on completion → The history does not stay exposed. **The auditor wants to verify it themselves.** - Gives them read-only access to the file → They verify without intermediaries. --- --- id: KB-TZ-008 url: https://app.codecontract.io/help/traceability-and-compliance/someone-sent-me-a-verifiable-document idioma: en categoria: trazabilidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-GL-005] citadoPor: [KB-SC-016] --- # Someone sent me a document and I want to check it _How to verify a document you received, with no account, in a minute._ **Responde a:** how do i verify a document sent to me · check whether a certificate is genuine · verify a pdf with a qr code · is this document fake If you have received a document claiming to be verifiable, you can check it yourself. No account, no permission from the sender, no need to trust anyone: that is precisely the point. ## How to do it | What you have | What to do | | --- | --- | | The file | Upload it to the public verification page | | A QR code on the document | Scan it with your phone camera | | Only a paper printout | Ask for the original file: a photocopy cannot be verified | ## What each answer means **En corto** - Matches: it is exactly the document that was sealed, on the date stated. - Does not match: that file has changed since, even by a comma. - Not found: that document was never sealed here. > [!WARNING] > "Does not match" does not necessarily mean someone is deceiving you. Reprinting a PDF, re-saving it from another program or converting it changes the file. Ask for the original before drawing conclusions. > [!IMPORTANT] > Verification checks that the document has not changed and when it existed. It does not check that what it says is true, nor that the sender is who they claim. If it arrived from someone you were not expecting, that still deserves a phone call. > [!NOTE] > The check works the same years later, as long as you keep the file. It does not depend on any relationship with the sender. **Do I need to register?** No, and that is deliberate: whoever verifies is usually an outsider. **Does the sender find out?** Verifications are logged. **Can I verify from a phone?** Yes, including scanning the code. ## Ejemplos **A client receives a certificate from their supplier and wants to check it is genuine.** - Scans the code on the document → Confirms in twenty seconds that it is the one that was sealed, without phoning anyone. **A document arrives and there is doubt whether it is the right one.** - Checks its fingerprint on the verification page → The doubt is settled in seconds. **The file was opened and no longer matches.** - Requests the unopened original → The check comes out correct. **The document arrived through a channel that recompresses it.** - Requests it again uncompressed → The fingerprint matches again. **It does not match and there is no explanation.** - Documents the check and consults the issuer → The case is handled with the trail in view. **Nobody knows what the check actually asserts.** - Checks what the result says → The proof is not credited with more than it says. --- --- id: KB-TZ-009 url: https://app.codecontract.io/help/traceability-and-compliance/exporting-everything-to-change-system idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-TZ-005] citadoPor: [KB-IN-013, KB-LE-023] --- # If one day you want to change system _What you can take, in what format, and why it is worth knowing beforehand._ **Responde a:** export all my documents · move to another platform · how do i get all my information back · migrate documents to another system This is a question worth asking before you start, not after three years inside. And it is a reasonable one: what you store here are your documents, and getting locked into a tool is a real risk. ## What you can take | What | In what format | | --- | --- | | The documents | Exactly as uploaded, untransformed | | Extracted data | In spreadsheet format | | Dates and history | With the export, not separately | | Signature evidence | Inside the signed copy | > [!IMPORTANT] > That documents come out **exactly as they went in** is what genuinely matters. A system returning your PDFs converted to another format returns files that no longer match their fingerprint, and with that you lose the ability to verify them. ## What does not travel the same The processes you built, templates and workflows are specific to each tool and do not transfer as-is to any other. What transfers is what matters: the documents, their data and their dates. **En corto** - Test the export once at the start, not when you need it. - Keep a copy of critical material outside, if your sector requires it. - And confirm signatures still verify after exporting. > [!WARNING] > If you export and someone then converts the files "to tidy them up", you will have lost the verifiability of everything signed. Originals are kept as they came out; copies in other formats are additional copies, not replacements. > [!NOTE] > Asking this before contracting any tool — this one or another — is a good habit. A clear answer is a signal; a vague one is too. **Can I export only part?** Yes, by client, by site or by period. **Does an exported signature still hold?** Yes, as long as you keep the original file untransformed. **How long does a large export take?** It depends on volume; test it on a portion before needing it whole. ## Ejemplos **A company tests a full export six months in, without needing it.** - Checks the PDFs come out untransformed - Verifies an exported signature → They know exactly what they can retrieve, and that confidence lets them put the important material inside. **A contract is signed without asking how to get out.** - Asks the export format and cost before signing → The exit is verified rather than assumed. **Documents come out loose without their context.** - Checks the export preserves the structure → What is exported stays usable. **Migration happens and the history stays in the old system.** - Includes the history in the migration plan → Migration does not cut the history. **The export is requested once you already want to leave.** - Asks for a test export beforehand → The exit is known without pressure. **Nobody knows what happens if the provider closes.** - Keeps a periodic copy of what matters → A third party failing does not take the archive. --- --- id: KB-TZ-010 url: https://app.codecontract.io/help/traceability-and-compliance/what-to-do-if-someone-denies-receiving-something idioma: en categoria: trazabilidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-005, KB-TZ-002] citadoPor: [KB-TZ-012, KB-TZ-015] --- # "I never received that" _The most repeated sentence in a dispute, and what answers it._ **Responde a:** the client says they did not receive the document · prove i sent something · they deny receiving the notice · proof of sending and receipt It appears in any dispute and nearly always in good faith: the person genuinely does not remember, or it reached someone who has left, or it landed in spam. What decides the conversation is not who is right, but what can be shown. ## The four levels of answer | What you can prove | How strong it is | | --- | --- | | That you sent it | Medium: proves it left, not that it arrived | | That it was delivered | High: the recipient's server accepted it | | That it was opened | Very high, with date and time | | That they signed it | Decisive: no longer receipt, but acceptance | > [!IMPORTANT] > The jump from the first to the third changes the conversation. "I sent it to you" invites a reply; "it is recorded as opened on the 4th at 10:12" does not, and usually ends the discussion without anyone losing face. ## How to show it without it looking like an attack Delivery matters. "It must have gone astray — our record shows it was opened on the 4th; I am resending it" achieves the same as an accusation without damaging the relationship. Evidence exists to close a doubt, not to win an argument. **En corto** - Show the fact, not the conclusion. - Offer to resend it in the same sentence. - And if the record says it was never opened, say that too: sometimes they are right. > [!WARNING] > If the record shows a bounce or that it was never opened, the problem is yours and it pays to admit it fast. Insisting it was sent when the log says it never arrived destroys the credibility of all your other records. ## When it repeats with the same person It stops being a dispute and becomes data: that address does not work, or that person is not the right one. Fix the contact instead of repeating the conversation every quarter. > [!NOTE] > For anything with consequences, proving arrival is not enough: send it for signature. The gap between "I told you" and "you accepted" is everything. **How long is that record kept?** According to your retention policy. **Does it hold before a third party?** It is the kind of evidence submitted; its weight is assessed by whoever decides. **What if someone else at their company opened it?** The record shows it was opened from that recipient; no system says who was at the screen. ## Ejemplos **A client denies receiving notice of a cost overrun and the relationship is a long one.** - Shows them the open record and offers to resend it → The doubt closes without anyone losing face, and the client stays a client. **The other side says they never received it.** - Checks the date and delivery status → It is on record when it was delivered. **It was emailed and there is no record.** - Uses a channel that leaves a trail for what matters → Delivery is demonstrable. **It shows as delivered and they still deny it.** - Provides the record with its date and recipient → The dispute closes on data. **It is resent without checking the first send.** - Checks first what is on record → Duplication and confusion are avoided. **The right recipient was somebody else.** - Checks the recorded address → The error is located rather than argued. --- --- id: KB-TZ-011 url: https://app.codecontract.io/help/traceability-and-compliance/responding-to-a-formal-request idioma: en categoria: trazabilidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-001, KB-TZ-007, KB-TZ-017] citadoPor: [KB-LE-015, KB-PR-017, KB-TZ-018, KB-TZ-021] --- # Responding to a formal request _A court, an inspectorate or a lawyer requests documents with a deadline. What you hand over and what you do not._ **Responde a:** served with a document request · responding to an inspection deadline · what to hand over in a formal request · producing documents for proceedings A notice arrives requesting documentation about a period or a specific relationship, usually with a short deadline. The habitual reaction — searching in a rush and sending everything that turns up — is what creates the problems that follow. ## The three expensive mistakes | Mistake | Why it costs | | --- | --- | | Handing over too much | You put information nobody asked for into the proceedings | | Handing over too little without saying so | An unexplained omission interprets itself | | Handing over without recording what you handed over | Months later you will not know what left here | > [!IMPORTANT] > The third is the most underestimated. Without an exact record of which files were produced and on what date, you cannot rebut a later claim about what you supplied — nor show you met the deadline. ## How to respond in an orderly way 1. **Define what is being asked, in writing** — Period, people, document type. If it is ambiguous, ask before searching. 2. **Search by identifier, not by date** — A tax ID, case number or registration finds what a date hides. 3. **Assemble it as its own file** — The response file, separate from the original, with an index. 4. **And record what was produced and when** — With the exact list. That record matters as much as the documents. > [!WARNING] > If what is requested contains third-party personal data outside the scope, do not simply include it: take advice first. Complying with a request does not lift your obligation to protect the data of people who are not party to it. ## What helps a great deal when it happens **En corto** - Sealed documents: you can prove they existed on their date. - An access record of who saw them and when, if that is disputed. - And a history that includes sends: sometimes what is requested is not a document but proof that something was communicated. > [!NOTE] > Preparing this calmly costs very little and is only appreciated under pressure. If you know a matter could end in a formal request, complete the file now: searching against a deadline is what causes over-disclosure. **Can it be produced electronically?** Usually accepted and it makes recording easier; follow what the notice says. **What if we cannot find something that existed?** Explain it, with what you do have. An explained gap is not the same as silence. **Can I delete anything while a request is live?** No. From that moment retention stops being your decision. ## Ejemplos **A company receives a request covering two years of dealings with a supplier.** - Searches by the supplier's tax ID and builds an indexed response file - Records the exact list produced and the date → Meets the deadline without disclosing anything outside scope and keeps proof of what left. **A formal request arrives with a short deadline.** - Checks what exists before answering → The response is prepared knowing what you have. **Too much is handed over just in case.** - Selects what matches what was asked → No unnecessary information is provided. **There is no record of what was handed over.** - Records the bundle and its date → The handover is demonstrable afterwards. **A document is missing and no search is on record.** - Documents the search and its outcome → A proven absence has value. **Each department submits their own part separately.** - Centralises the response in one file → A coherent set is handed over. --- --- id: KB-TZ-012 url: https://app.codecontract.io/help/traceability-and-compliance/giving-notice-in-time-and-proving-it idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-004, KB-TZ-010] citadoPor: [KB-CC-013, KB-SC-014, KB-TZ-015] --- # Giving notice in time and proving it _A notice period, a claim or a time-bound communication. What counts is not sending it: it is proving it._ **Responde a:** how to prove i sent a notice · recorded communication without registered post · proving i gave notice before the deadline · notification with proof of delivery Some communications only count if they arrive in time: notice of non-renewal, a claim over a defect, notification of an incident. And in all of them, the one who must prove notice was given is you, not the other party claiming they never heard. ## What you must be able to prove | Element | Why it matters | | --- | --- | | What you sent | The exact content, not "I told them that…" | | When | The only thing the deadline argument turns on | | To whom | That it was the right recipient, not a generic mailbox | | And that it arrived | Delivered, and where possible, opened | > [!IMPORTANT] > The third defeats the most claims. A notice sent to an obsolete contact address or a general mailbox can be treated as not given, even with proof that it left. ## How to do it 1. **Check the recipient before sending** — The contract usually says to whom and how notice must be given. That is where to look. 2. **Send with a record, not a loose email** — Keep evidence of sending, delivery and, where the channel allows, opening. 3. **Certify the content sent** — It fixes exactly what the document you sent said on that date. 4. **And keep it in the relationship's file** — Not in the sender's inbox, which is where it eventually disappears. > [!WARNING] > If the contract requires a specific form (recorded post, a specific address), that form governs. A channel with a better trail does not replace what was agreed: use it **as well**, not instead. ## When the deadline is tight **En corto** - Send by two routes if there is little margin: it counts as two actions and avoids missing the deadline. - Do not wait for the perfect wording if time is running out: a correct, brief notice in time beats an impeccable one out of time. - And record it the same day, not when the matter closes. > [!NOTE] > The resulting evidence is useful even when there is never a dispute: in many relationships the mere existence of the record changes the conversation, because the other side knows there is no ambiguity about what was said and when. **Is an ordinary email enough?** It can be, but proving delivery is harder. With send and delivery records, much better. **What if the recipient never opens it?** Delivered and unopened usually suffices; not opening is not a defence. **Does a text message count?** As a supplement yes; for formal notice, follow the contract. ## Ejemplos **A company sends non-renewal notice to the usual email and the supplier denies receiving it.** - Checks in the contract who notice must go to - Sends with delivery tracking and certifies the content → The next notice is indisputable: content, date, correct recipient and delivery all on record. **A warning goes out and there is no record of when.** - Sends it through a dated channel → The moment of warning is demonstrable. **A warning comes late and there is a dispute over whether there was time.** - Checks the warning's recorded date → The dispute closes on the figure. **The warning reaches somebody who could not act.** - Checks the recipient before sending → The warning proves something useful. **Warnings go out several times and only the last is on record.** - Records each warning with its date → The chasing is documented. **The other side says the warning was not clear.** - Keeps the exact text sent → What was communicated can be read. --- --- id: KB-TZ-013 url: https://app.codecontract.io/help/traceability-and-compliance/the-deletion-you-do-have-to-do idioma: en categoria: trazabilidad audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-003, KB-TZ-006] citadoPor: [KB-CF-015, KB-TZ-017] --- # The deletion you do have to do _Keeping everything forever is not prudence: in some cases it is a breach._ **Responde a:** when personal data must be deleted · document retention policy · cannot keep everything indefinitely · deleting documents with personal data The default reflex is to keep everything just in case, and for most documents that is reasonable. For those containing personal data it is not: keeping them beyond what is necessary stops being prudence and becomes a problem. ## The three groups | Group | Criterion | Examples | | --- | --- | --- | | Kept by obligation | A legal period sets the minimum | Tax, employment, safety | | Kept by interest | While a claim remains possible | Contracts, deliveries, evidence | | Deleted | When no longer needed for the purpose collected | Rejected applications, visitor logs, ID copies | > [!IMPORTANT] > The third group is the one almost nobody has defined, and the only one where not acting is itself the breach. A CV from someone you did not hire four years ago is not kept out of prudence: it is kept because nobody decided what to do with it. ## How to build a policy that runs itself 1. **List the document types you hold** — By type, not by document. Usually fewer than twenty. 2. **Assign a period to each type** — Using the criteria above and, when unsure, asking your advisers. 3. **Have the clock start from an event, not from upload** — "Four years from contract end", not "from when it was uploaded". 4. **And review it annually** — Obligations change and so do the document types you handle. > [!WARNING] > The expensive mistake is automatic deletion with no exceptions. If there is open litigation or a live request, retention stops being your decision: you must be able to suspend deletion for what is affected, and know what that is. ## What is not deleted when you delete **En corto** - The record that it existed and was deleted, with a date. - Aggregate data that identifies nobody. - And anything covered by a different obligation, even from the same file. The first line matters: being able to show something was deleted when it should have been is as useful as being able to show it was kept. > [!NOTE] > If someone exercises their right to erasure, this is already half done: you know where their material is, what can be deleted and what must be kept by obligation, which is exactly what you must tell them. **How long must each thing be kept?** It depends on type and country. That is the part to check rather than improvise. **What if I delete something that was needed?** Hence assigning periods by type and reviewing them; deleting without criteria is worse than not deleting. **Can it be automated?** The warning yes. The decision to delete is better confirmed by a person. ## Ejemplos **A company keeps CVs from recruitment processes five years old.** - Defines periods by document type and start event - Suspends deletion for anything caught by open litigation → Stops accumulating data it should not hold and can show when each item was deleted. **Everything is kept and grows unchecked.** - Reviews what has passed its period → The archive stops growing without criteria. **Things are deleted without checking whether they had to be kept.** - Checks the policy before deleting → Deleting stops being a gamble. **A client asks for their material to be deleted.** - Locates where it appears and acts on the policy → The request is handled on a basis. **Deletion happens and there is no record of it.** - Records what was deleted and when → What was done is demonstrable. **Nobody is responsible for reviewing the periods.** - Schedules the periodic review → Deletion happens because it is due, not because somebody remembers. --- --- id: KB-TZ-014 url: https://app.codecontract.io/help/traceability-and-compliance/the-certificate-that-expires-in-august idioma: en categoria: trazabilidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-001, KB-TD-002] citadoPor: [KB-LE-013, KB-PR-018, KB-PR-019] --- # The certificate that expires in August _The expiries that fall at the worst time of year, and how to stop suffering them._ **Responde a:** expiries during holidays · certificate expired in august · renewals during the holiday period · warnings with enough lead time Some expiries take care of themselves and others always land badly: August ones, the week between Christmas and New Year, and the first day of the year. It is not bad luck: the warning arrives when whoever must renew is away, and so is whoever could cover for them. ## The three bad moments | When | Why it fails | Recommended margin | | --- | --- | --- | | August | The third parties renewing are also on holiday | Two months | | Year end | It collides with closing and everyone is stretched | Two months | | Early January | The warning arrived at Christmas and nobody saw it | Three months | > [!IMPORTANT] > The margin does not depend on how long you take: it depends on how long whoever issues the document takes. A medical certificate, an official certificate or a policy renewed through a broker all depend on third parties with their own holidays. ## How to fix it, once 1. **Set the margin per document type, not one for everything** — Insurance does not take as long as an audited certification. 2. **And a larger margin for anything expiring in a bad period** — It is the only rule that ends the annual suffering. 3. **With a named owner, not "the department"** — And a deputy for the period when that owner is away. 4. **And review in June what expires in August** — One review a year at the right moment beats twelve warnings. > [!WARNING] > The classic error is setting "one month before" for everything. For a document renewed in an afternoon it is excessive; for one requiring an external audit it arrives late and guarantees a lapse — with the peculiarity that the warning worked perfectly. ## If it has already lapsed **En corto** - First, know what stops: sometimes nothing, sometimes everything. - Communicate before you are asked, especially if a client is affected. - And record the date it was detected and what was done. That record matters: the difference between a managed lapse and an ignored one, before an inspector or a client, is precisely being able to show when you saw it and what you did from then on. > [!NOTE] > When the lapsed document belongs to a third party — a supplier, a subcontractor — the decision on whether they keep working is yours and is best written down, even when the answer is yes. **Can several people be warned?** Yes, and for critical items it helps: one person may be away. **What if the third party does not renew in time?** That is your decision, not an accident: block, escalate or accept the risk. **How many warnings are reasonable?** Two: one with margin and a final call. More get ignored. ## Ejemplos **A company finds two or three lapsed certificates every August.** - Sets a two-month margin for summer expiries and names a deputy - Reviews in June what expires in August → Summer stops being the month of emergency renewals. **A certificate expires in the middle of the holiday period.** - Brings forward warnings for anything falling in August → Renewal happens before nobody is around. **The warning arrives and whoever should act is away.** - Also addresses the warning to a deputy → Renewal does not wait on one person. **Renewal happens late and there is a gap in cover.** - Adjusts the lead time to the process's real duration → No day is left uncovered. **Nobody knows what expires in the coming months.** - Checks expiries by date → The calendar gets planned. **The provider takes longer than expected to renew.** - Adds their response time to the lead time → The margin includes the wait. --- --- id: KB-TZ-015 url: https://app.codecontract.io/help/traceability-and-compliance/when-each-side-tells-a-different-story idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-010, KB-TZ-012] citadoPor: [KB-TZ-018, KB-TZ-019] --- # When each side tells a different story _Neither side is lying: each holds a fragment. How to reconstruct what actually happened._ **Responde a:** the supplier says they did send it · conflicting versions of what happened · reconstructing what happened in a case · date discrepancy with a client In almost every argument about a delay or a breach, both sides are telling the truth: each describes what they see from their end. You see it never arrived; they see they sent it. Both can be true at once, which is why arguing from memory gets nowhere. ## The four usual mismatches | They say | You see | What usually happened | | --- | --- | --- | | "I sent it to you" | No record of anything | It went to another address or a mailbox nobody opens | | "I already signed" | Still outstanding | They signed an old send, or opened without completing | | "We warned you about the delay" | No record | It was said by phone and nobody wrote it down | | "That is not what we agreed" | You remember it differently | It was settled in an email thread with no summary | > [!IMPORTANT] > All four share a root: **the information existed and did not end up in the shared place**. And all four resolve equally badly afterwards and equally well in the moment — so the work is not winning the argument, it is making the next one impossible. ## How to reconstruct what happened 1. **Start with what has an objective date** — Send statuses, deliveries, uploads, signatures. They do not depend on anyone's memory. 2. **Put both sequences side by side** — Yours and theirs, by date. The gap shows itself. 3. **Ask about specifics, not generalities** — "Which address did you send it to and on what day?" moves forward; "are you sure you sent it?" stalls. 4. **And note the outcome in the file** — Even with no blame to assign: next time, that note is the starting point. > [!WARNING] > The nuance that changes the tone: most of these mismatches are not bad faith, they are channel problems. Someone sent to an obsolete address, or replied to an old email, or spoke to a person who no longer handles the matter. Come in accusing and the other side defends itself and you stop learning what happened; come in asking about detail and they tell you. ## What prevents the mismatch next time **En corto** - Having submissions come through the link rather than by email: then it is recorded on both sides at once. - Having what is agreed by phone summarised in writing the same day. - And sending requests to a named person, not a shared mailbox. The first removes the most arguments outright: when the document comes in through the shared route, there are no longer two stories — there is one that both sides can see. > [!NOTE] > If the discrepancy is heading for a claim, seal your account along with what supports it before sending. It does not prove you are right, but it fixes what you said and when, which is what gets disputed later. **What if the other side really is wrong?** Showing the dated sequence convinces far more than insisting. **Should we show them our record?** Nearly always yes: it turns an argument about perceptions into one about facts. **What if nothing was recorded at all?** Then the conversation is about how to work from now on, not about who failed. ## Ejemplos **A supplier insists they sent the certificate and the company has nothing.** - They lay both sequences out by date and ask which address it went to → It turns out it went to a decommissioned generic mailbox, and submissions move to the link. **Each party tells a different version of what happened.** - Checks the recorded sequence with its dates → The dispute closes by looking. **There is an argument about who said what and when.** - Keeps the communications with their dates → What was said can be read. **One version rests on an email that no longer exists.** - Stores what matters outside personal inboxes → The evidence outlives the people. **The story is reconstructed from memory.** - Checks the file's history → The reconstruction comes from the record. **What happened must be explained to a third party.** - Shares the sequence with controlled access → The third party reads rather than believes. --- --- id: KB-TZ-016 url: https://app.codecontract.io/help/traceability-and-compliance/who-authorised-this-exception idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-001, KB-IC-014] citadoPor: [KB-TZ-019, KB-TZ-020] --- # Who authorised this exception _Letting something incomplete through is a legitimate decision; being unable to say who took it is not._ **Responde a:** recording an approved exception · who authorised bypassing the procedure · justifying an off-process approval · decision traceability No company follows its own procedure one hundred per cent of the time, and that is fine: there are emergencies, waiting customers and situations the procedure never anticipated. What separates an orderly company from an improvising one is not having no exceptions — it is knowing which there were, who authorised them and why. ## The most repeated exceptions | Situation | What is bypassed | What must be written down | | --- | --- | --- | | A supplier comes in with incomplete documentation | The requirement to be current | What is missing, until when, and who accepts it | | Something is signed without the usual review | The approval step | Who decided and with what information in front of them | | Out-of-spec material is accepted | The quality criterion | Who accepts it and for what specific use | | Payment goes out without a matched delivery note | The prior reconciliation | Who authorises and what will be done afterwards | > [!IMPORTANT] > In all four, what gets asked for later is **never the missing document**: it is who decided to proceed without it. An exception with a name, a date and a reason is a management decision; the same exception without them is a breach, even if the outcome was identical. ## How to record it without building a new procedure 1. **In the same file where it happens** — Not in a separate exceptions register nobody maintains. 2. **With who authorises, not "it was authorised"** — A name. It is the difference between a decision and a fait accompli. 3. **With the condition and the deadline** — "Comes in today, supplies insurance by Friday" is an exception; "comes in" is a hole. 4. **And with the closure** — If the condition was met, note it; if not, that is information too. > [!WARNING] > The fourth point is barely ever done and it changes the meaning of everything above. An exception opened and never closed stops being an exception: it becomes the new way of working without anyone deciding it. If a review shows many open, the problem is no longer the exceptions — it is that the procedure asks for something operations cannot deliver. ## What it is for later **En corto** - In an audit: showing controlled exceptions beats pretending there are none. - In a claim: it places who decided what, and on what information. - And internally: if they rise month on month, it is the earliest sign something does not fit. The last is the most useful and the least examined. Exceptions move before the compliance percentage does, because they signal real friction while the numbers still look fine. > [!NOTE] > None of this needs a form: it is enough that the decision is written where it happens, with who and why. A separate exceptions register survives three months; a note in the file survives as long as the file. **Does having recorded exceptions look bad?** Far worse is not having them recorded and having them surface on their own. **Who should be able to authorise them?** Whoever answers for that area. If anyone can, it is not an exception: it is the real process. **What about genuine emergencies?** Authorise them the same way, and note it the same day. What does not work is never noting it. ## Ejemplos **A company lets a subcontractor on site without current insurance because of an urgency.** - Records who authorises it, what is missing and until when - Closes the exception when the policy arrives → The audit sees a controlled decision instead of an unexplained access. **An exception is made and nobody knows who authorised it.** - Records who authorised and when → The authorisation has a name and a date. **The exception is requested by phone.** - Asks for the authorisation in writing → The exceptional stops depending on two memories. **The exception repeats and nobody notices.** - Checks how many times it has been authorised → The exception stops becoming the rule unnoticed. **Authorisation is given without recording the reason.** - Records the reason alongside the authorisation → Months later it is understood why. **A review asks about an old exception.** - Checks the authorisation log → You answer from the record. --- --- id: KB-TZ-017 url: https://app.codecontract.io/help/traceability-and-compliance/when-what-you-must-keep-changes idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-013, KB-NO-011] citadoPor: [KB-TZ-011] --- # When what you must keep changes _A new obligation, a new criterion or a client demanding more: what to do with everything already filed._ **Responde a:** the rules changed what about old records · applying a new criterion to filed documents · they now require documentation we did not keep · reviewing the archive after a requirements change Every so often something changes: a new obligation, a client tightening requirements, or you yourselves deciding to ask for more. The question that always appears is the same and is rarely answered well: what do we do with everything from before? ## The three possible answers, and when each applies | Answer | When it makes sense | Risk | | --- | --- | --- | | Forward only | When the change is yours and there is no retroactive duty | Living with two criteria for a while | | Forward and at renewal | The usual: everyone catches up when their turn comes | Taking a full cycle to be complete | | Everything, now | When there is a real deadline or a client auditing soon | The most expensive and the most resisted | > [!IMPORTANT] > The second works in most cases and is the least considered, because it sounds like half-measures. It is not: **using the renewal you already run turns a project into a routine**. Asking a supplier for a new document while you are already asking for their annual renewal costs nothing; asking separately, in May, costs a whole campaign. ## What to decide before starting 1. **Whether the change affects what is done or only what is new** — A new requirement is not the same as a different criterion for judging the same thing. 2. **From what date it applies, written down** — It is what later explains why two files from the same year look different. 3. **What happens to what no longer complies** — Flagged, re-requested, accepted as is? Decided once, not case by case. 4. **And who owns the transition** — By name, or it stalls in month two. > [!WARNING] > The mistake that causes most trouble is applying the new criterion backwards **without leaving a trace that it changed**. If a year from now someone looks at a three-year-old file and sees something missing that was not required then, the natural conclusion is that you skipped it. Recording from when each criterion applies is not bureaucracy: it is what stops your own archive accusing you. ## What can almost always be reused **En corto** - The annual renewal you already run. - Onboarding of any new supplier or client, which asks for the new thing from day one. - And the first time an old file is touched for another reason. That third costs the least effort and covers the most ground: if every time someone opens an old file they leave it at the current criterion, the archive catches up by itself within months. > [!NOTE] > If the change comes from an obligation rather than your own criteria, **its scope and start date are a question for your adviser**: some changes look only forward and some do not. What is described here is how to organise the transition once you know which case is yours. **Do closed files have to be redone?** Absent an express duty, no: what is closed is judged by the criteria of its time. **What if a client demands the new criterion for old material?** That is a negotiation, not an obligation: quantify what it involves before agreeing. **Should suppliers be told about the change?** Yes, and in the renewal request itself: it lands better than a separate email. ## Ejemplos **A company decides to require a new document from all its suppliers.** - Adds it to onboarding and the annual renewal instead of launching a separate campaign - Records the date it applies from → Within one cycle it is complete, with no extra campaigns and without the old archive looking deficient. **What must be kept changes and nobody reviews the old material.** - Reviews which files are affected → The change reaches what already existed. **The new criterion is applied only to new material.** - Decides what happens to the earlier material → The archive is coherent. **Nobody knows from when the new criterion applies.** - Records the date of the change → You can say which criterion applied when. **A client asks why their file holds less.** - Checks which criterion applied then → The difference is explained. **The change is communicated verbally.** - Keeps the criterion written and accessible → The team applies the same thing. --- --- id: KB-TZ-018 url: https://app.codecontract.io/help/traceability-and-compliance/the-file-of-an-incident idioma: en categoria: trazabilidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-015, KB-TZ-011] citadoPor: [KB-TZ-020] --- # The file of an incident _While it is happening, nobody documents. Afterwards, what gets reconstructed is exactly what gets questioned._ **Responde a:** how to document an incident · reconstructing what happened after a problem · incident report with a client · what to keep when something goes wrong A delivery that arrives damaged, a breakdown, a complaint that escalates, a fault that hits a client. For the first few hours everyone is fixing it, which is what they should be doing. The problem arrives three weeks later, when somebody asks for a report and it has to be reconstructed from five people's memories. ## What is kept automatically and what must be captured | Element | Generated on its own | Must be captured | | --- | --- | --- | | Emails and messages with the client | Yes, with their time | — | | Documents contributed during the incident | Yes, with who uploaded them | — | | What was decided and why | No | Yes: a short note the same day | | Calls and corridor conversations | No | Yes, and it is what is always missing | | Photos of the state of things | No | Yes, at the time: later it no longer looks the same | > [!IMPORTANT] > The last three rows decide the report, and there is a reason they cannot wait: **anything written after the outcome already knows how it ended**. A note drafted the same day, with the incomplete information available then, shows you decided on reasonable grounds; the same note written three weeks later looks like — and sometimes is — a justification. The difference is not the content, it is the date. ## The four notes worth a whole report 1. **What happened and when you found out** — With the time. «When did you know» is everyone's first question. 2. **What was decided and on what information** — Including what you did not have: that is what justifies the decision. 3. **Who was notified and when** — Client, insurer, supplier, whoever applies. 4. **And what was left open at the end of the day** — It turns the file into something someone else can pick up. > [!WARNING] > What breaks most in practice is not missing data: it is that **the incident is handled on a private channel** — a messaging group, calls, emails between two people. When the claim arrives, half of what happened sits on the phone of someone who may be off sick or gone. It is enough to dump each decision into the file the same day, even if the conversation carries on wherever it is comfortable. ## And when the incident touches personal data **En corto** - The clock starts when someone in the organisation spots it, not when it is confirmed. - Which is why the detection time is noted the moment it is known. - And decisions are noted even before you know the scope. > [!NOTE] > Where personal data is involved there are notification duties with their own deadlines and recipients — the **GDPR** in Europe and, depending on the sector, frameworks such as **NIS2**. **What applies to you and within what deadline is for your adviser to determine**; what matters here is that without the detection time noted, that conversation starts on the wrong foot. **Is it worth documenting a small incident?** Four lines. The ones that end in claims all looked small at first. **What if the decision turns out wrong?** Note it anyway. What is judged is whether you decided reasonably, not whether you were right. **Who should write it?** Whoever is handling it, that day. Not the boss, three weeks later. ## Ejemplos **A company handles a damaged delivery over a messaging group and it ends in a claim.** - Dumps each decision and the detection time into the file the same day → The report is written by reading the file, not by reconstructing five people's memories. **The incident is documented days later.** - Records what happened at the moment → The account is exact rather than reconstructed. **Each person keeps their own notes.** - Gathers everything into an incident file → The sequence can be reconstructed. **There is no record of who decided what during the incident.** - Records decisions with author and time → What was done is explicable. **The incident is closed with no conclusions.** - Records what was learned and what changed → The next incident starts better. **A third party asks for the incident file.** - Shares what is relevant with controlled access → It is handed over ordered and verifiable. --- --- id: KB-TZ-019 url: https://app.codecontract.io/help/traceability-and-compliance/verbal-agreements-and-how-to-put-them-in-writing idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-015, KB-TZ-016] citadoPor: [KB-TZ-020] --- # Verbal agreements: how to put them in writing _They are closed by phone, on site or over lunch, and months later each side remembers something different._ **Responde a:** how to record a verbal agreement · confirming by email what was agreed · we agreed by phone and now they deny it · minutes of a client meeting Most decisions that later matter are not taken in writing. They are taken in a four-minute call, on a site visit or in a corridor conversation with the client. Nobody is going to stop working like that — what can change is what happens in the ten minutes afterwards. ## The confirmation email, and why it works | Part of the email | What it is for | | --- | --- | | What was agreed, in short sentences | It is what will be read a year from now | | Who was there and when | It places the agreement in time | | What each side does and by when | It turns the agreement into something checkable | | «If I have misunderstood, tell me» | It invites correction, and that is the key | > [!IMPORTANT] > That last line is what turns a note into evidence: **an email describing what was agreed and inviting correction carries weight if it goes uncorrected**. Not because silence equals signing, but because anyone later holding a different version has to explain why they read that and said nothing. It is the difference between «I remember it differently» and «I wrote it to you that same day and you did not deny it», and it costs four sentences. ## How it is done in practice 1. **The same day, before it cools** — By the next day it is remembered differently, and it shows in the writing. 2. **Neutral and unembellished** — A summary they recognise; if it reads like a trap, they answer defensively. 3. **What was left open, too** — Saying what was NOT agreed stops it being assumed later. 4. **And filed where the record is** — In your personal inbox nobody else will find it. > [!WARNING] > There is a detail about recordings that surprises people: **recording a call is not the easy answer it looks like**. It depends on where you are and who is on the other end, it usually requires telling them, and it changes the tone entirely — people speak differently knowing they are recorded. A confirmation email achieves almost the same without any of that. **If you still want to record, ask your adviser first**. ## When the agreement really matters **En corto** - If it changes prices, deadlines or responsibilities, an email is not enough: that belongs in a contract or an addendum. - And if the other side wants to «leave it on a handshake», that is exactly when to write it down. - An agreement nobody minds putting in writing is rarely an agreement. > [!NOTE] > What weight a verbal agreement carries, and what is needed for it to bind, depends on the type of contract and your country. **Your adviser answers that**; here it is about not being left with nothing to show once the conversation is forgotten. **What if they never reply?** That silence already works for you. What does not work is never sending it. **Does a phone message count?** It does, and it gets lost. Copy it into the record the same day. **Does writing it look distrustful?** Framed as a working summary, no. And whoever objects is usually the signal. ## Ejemplos **A company agrees a deadline change with a client by phone and writes nothing.** - Sends four sentences that same day with what was agreed and what stayed open → When the client remembers another date, there is an email from that day nobody denied. **Something is agreed by phone and nothing remains.** - Sends an email summarising what was agreed → What was agreed stops depending on two memories. **The summary goes out and nobody confirms.** - Asks for explicit confirmation → The agreement has two parties. **The agreement is kept in a personal inbox.** - Files it with the contract or matter → It lives where people will look. **Months later there is a dispute over what was agreed.** - Checks the summary with its date → The dispute closes by reading. **Successive changes are agreed and the thread is lost.** - Files each agreement with its date → The sequence of what was agreed is legible. --- --- id: KB-TZ-020 url: https://app.codecontract.io/help/traceability-and-compliance/recording-what-was-decided-against idioma: en categoria: trazabilidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-016, KB-TZ-018, KB-TZ-019] citadoPor: [KB-TZ-005] --- # Recording what was decided against _Records keep what was done. What was decided against leaves no trace — and it is exactly what gets questioned later._ **Responde a:** how to justify not doing something · we rejected a batch and did not record it · proving we considered and dismissed something · documenting a decision not to act A file tells what happened well: what was requested, what arrived, who approved it. What it does not tell is what almost happened and did not — and when someone reviews it a year later, that is the question: «why did you do nothing?». ## Decisions that leave no trace by themselves | Decision | What the file shows | What is missing | | --- | --- | --- | | Rejecting a material or a batch | That it did not come in | Why it was rejected and who decided | | Refusing a change the client asked for | Nothing | That it was considered, and on what grounds | | Ruling out a supplier | That they are absent | That they were looked at and why they did not fit | | Deciding something does not apply | A gap | That the gap is deliberate and not an oversight | > [!IMPORTANT] > The last row does the most damage in a review: **a gap and a decision to do nothing look identical from outside**. If a file lacks an analysis, a permit or a check, whoever looks cannot tell whether you assessed it and concluded it did not apply or simply missed it. And in doubt, they read the second. Two lines written that day — «not applicable because…» — turn a hole into a criterion. ## How to record it without creating bureaucracy 1. **In the file itself, not in separate minutes** — Where whoever asks will look, not where you would file it. 2. **What was assessed, on what information and who decided** — Three facts: the rest is surplus. 3. **The same day, with the information available then** — A justification written after the outcome shows. 4. **And if the decision later changes, add rather than amend** — Changing your mind on new data is normal and explains itself. > [!WARNING] > There is one case where this beats any other record: **when whoever decides against is not the person who raised it**. Someone flags a risk, it is assessed and the decision is to carry on. If that is not written down, the warning disappears and whoever gave it looks as if they never did — or, depending who tells the story, as the only one who knew. Recording it protects both sides, which is why it should be a habit rather than something done when trust is low. ## What does not need recording **En corto** - Routine decisions taken twenty times a day. - Anything already recorded by the act of doing it. - And anything with no consequences if questioned: if it does not matter, it takes no space. > [!NOTE] > In some sectors certain decisions not to act must be documented in a specific way. **What yours requires is for your adviser or quality manager to say**; here it is the general habit, which serves for everything else. **Is this not covering your back?** It is explaining a criterion. The difference is writing it before you know the outcome. **What if the decision was verbal?** Summarise it in writing that day: the same habit as with agreements. **Where do I keep it if there is no file?** In the supplier's or the project's: not in anyone's inbox. ## Ejemplos **A company considers an extra test on a batch, decides it does not apply and records nothing.** - Writes two lines that day on why it did not apply and who decided → At review, the gap reads as a criterion rather than an oversight. **A decision is taken not to do something and nobody notes it.** - Records the decision and its reason → The omission is a documented decision. **Months later it looks like an oversight.** - Checks the decision record → What was decided is told from what was forgotten. **A recommendation is rejected and there is no record.** - Records who decided and why → The decision has an owner. **Something is postponed indefinitely.** - Records the review date → What was postponed comes back to the table. **An auditor asks why something was not done.** - Shows the recorded decision → The answer is a decision rather than a silence. --- --- id: KB-TZ-021 url: https://app.codecontract.io/help/traceability-and-compliance/the-inspection-that-arrives-unannounced idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-011, KB-TZ-007] citadoPor: [KB-TZ-001] --- # The inspection that arrives unannounced _You do not prepare on the day it arrives. All you decide that day is who speaks and what is handed over._ **Responde a:** an inspection is here what do i do · what documents will an inspection ask for · preparing for a surprise audit · what to hand an inspector The buzzer goes on a Tuesday at half past nine. From then on, everything depends on two things already decided before they rang: whether the documents can be found, and whether anyone knows what to do. The rest —the nerves, the running about, the boss who does not pick up— follows from those two. ## The first fifteen minutes 1. **Identify who is in front of you and write it down** — Name, body and what they came to see. That is what tells you whom to call. 2. **Notify the designated person** — Designated beforehand. Improvising who accompanies is how too much gets said. 3. **Accompany — neither abandon nor obstruct** — Both extremes are remembered badly afterwards. 4. **And start taking notes from minute one** — What is asked, what is handed over, at what time. Your parallel record. > [!IMPORTANT] > What changes the outcome most is not having everything perfect: **it is the difference between «I have that, give me ten minutes» and «I'd have to look for that»**. The first is a company in control of its own affairs even if something is missing; the second opens the question of what else you will fail to find. So the real work is not a tidy folder, it is that any of you —not just one person— knows where everything is and can produce it in minutes. ## What to hand over and what not | Situation | The sensible move | | --- | --- | | A specific existing document is requested | Hand it over, and note which and when | | Something you cannot find is requested | Say so, and commit to a deadline in writing | | Something that does not exist is requested | Say it does not exist. Never create it afterwards | | General access to everything is requested | That is when you call your adviser before answering | > [!WARNING] > The two mistakes that turn a small problem into a large one are opposites and come from the same nerve: **filling gaps on the fly** and **stalling**. A document created or corrected and back-dated is infinitely worse than its absence, because it moves the conversation from a breach to something far more serious. And answering «our agent has that» with no deadline and no name sounds exactly like not having it. What works is the boring option: what exists gets shown; what does not, gets said, with a deadline. ## Afterwards, which is when almost nobody does anything **En corto** - Keep your own minutes: what was asked, what was handed over, who was present and at what time. - Close out the deadlines you accepted, even if nobody chases them. - Turn every gap found into a task with an owner and a date. - And tell your own people: an inspection is the most precise to-do list you will ever be handed free. > [!NOTE] > What powers each type of inspection holds, what a company must produce and how the visit should be documented depends on the body and the subject matter. **When a visit goes beyond the predictable, calling your adviser is part of the procedure, not an alarm signal**; here we cover what is genuinely yours: finding the papers and keeping a record. **Can I ask them to come back another day?** It depends on the type of visit. What you can always ask for is reasonable time to locate a document. **Do I have to grant access to everything they ask for?** That is not improvised: it is the moment to call your adviser before answering. **What if I spot a breach during the visit?** Note it and fix it afterwards, with a date. Correcting papers in the heat of it is the worst way out. ## Ejemplos **An inspection arrives unannounced and the person who knows where everything is is on holiday.** - Designates in advance who accompanies and writes down the map of where things live → The visit stops depending on one particular person being in that day. **A document cannot be found and the answer given is «our agent has it».** - Admits it cannot be found and commits to a specific deadline in writing → A gap becomes a deadline met instead of a suspicion. **Once the visit is over, nobody remembers exactly what was handed over.** - Keeps their own minutes from minute one: what is asked, what is given, at what time → Commitments can be closed and follow-ups answered without reconstructing anything. **An inspection arrives and everything is in physical folders.** - Keeps the file accessible from anywhere → It is shown there and then. **Nobody knows for certain what information exists.** - Keeps the archive organised and locatable → You can accompany them knowing what is being discussed. **There is no record of what was shown.** - Records what was provided, dated and in detail → What was done is documented. --- --- id: KB-TZ-004 url: https://app.codecontract.io/help/traceability-and-compliance/proving-you-gave-notice-in-time idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-GL-014] citadoPor: [KB-LE-002, KB-TZ-012] --- # Proving you gave notice in time _The commonest argument, and the easiest to close if the notice went out through here._ **Responde a:** prove i sent a notice · the client says we never told them · proof of sending and reading · email delivery receipt "You never told us" is the sentence that starts more commercial disputes than any other. And it is one of the few that can be closed with a fact instead of a conversation. ## The three levels of proof | Level | What it proves | Strength | | --- | --- | --- | | It was sent | That it left here, to that address, that day | Medium: does not prove arrival | | It was delivered | That the recipient's server accepted it | High | | It was opened | That someone opened it, and when | Very high | The jump from the first to the third is what changes the conversation. "I sent it to you" invites a reply; "it was opened on the 4th at 10:12" does not. > [!IMPORTANT] > Being opened does not prove it was read or understood. It is a strong fact, not proof of agreement: for that you need a reply or a signature. ## When to ask for a signature instead of giving notice If what you are communicating has consequences — a change of terms, a cost overrun, a deadline — a notice is not enough. Send it for signature: the difference between "I told you" and "you accepted" is everything. > [!WARNING] > An email from your personal inbox leaves none of this trail. If the notice matters, send it through the case. > [!NOTE] > In a dispute, what carries most weight is usually the dullest thing: the open record on a notice, not the thirty-page contract. **Do I know who opened it with several recipients?** It is recorded per recipient. **What if they opened it and say it was not them?** That is where having asked for a signature with a phone code helps. **How long is that record kept?** According to your retention policy. ## Ejemplos **A client disputes a cost overrun claiming they were never told.** - The notice record is retrieved - It shows the notice was opened the day after sending → The claim is withdrawn; next time that kind of communication is sent for signature, not as a notice. **A warning was given by phone and there is no record.** - Sends the warning through a channel that leaves a trail → The warning stops depending on two memories. **The other side says the warning never arrived.** - Checks the date and delivery status → It is on record when it was communicated. **A warning goes out and later there is a dispute over what was said.** - Keeps the exact text of the warning → What was communicated is demonstrable. **It must be proved that warning was given before a date.** - Checks the send log → The warning's date is beyond dispute. **The warning goes to the wrong recipient.** - Checks the recipient before sending → The warning proves something useful. --- --- id: KB-TZ-005 url: https://app.codecontract.io/help/traceability-and-compliance/what-gets-recorded-about-what-i-do idioma: en categoria: trazabilidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-GL-014, KB-TZ-020] citadoPor: [KB-TZ-007, KB-TZ-009, KB-TZ-010] --- # What gets recorded _Everything that touches a document leaves a trail, and that works in your favour._ **Responde a:** which actions are recorded · is it stored who opens a document · is there a log of what i do · am i being monitored on the platform Almost everything that happens around a document is recorded: who uploaded it, who opened it, who approved it, who downloaded it and when. It sounds like surveillance and it is not: it is what makes it possible to answer questions that would otherwise be one person's word against another's. ## What is recorded | Moment | What is kept | | --- | --- | | Upload | Who and when | | Send | To whom, on which channel, whether it arrived and whether it was opened | | Approval or rejection | Who decided, when and with what reason | | Download or view | Who accessed it and when | | Change to a value | The old value, the new one and who changed it | ## What it is for, in practice - Closing a "you never told us" with a date rather than an argument. - Showing an auditor that the control was genuinely applied, not merely written down. - Knowing who can answer a question about a two-year-old case. > [!IMPORTANT] > The log cannot be edited, not even by an administrator. That is what gives it value: a log someone could retouch would prove nothing, because whoever would retouch it is precisely who has the motive. > [!WARNING] > Recording who downloads what also protects you: if one day a document leaves where it should not, the question has an answer. > [!NOTE] > None of this has to be switched on: it exists from day one. The only decision is how long it is kept, which follows your policy. **Can anyone erase their trail?** No. **Can everyone see the log?** No, only administrators. It is sensitive information about people on the team. **Is a third party's activity recorded?** Yes: when they opened their link, what they delivered and when they signed. ## Ejemplos **Nobody remembers who approved a certificate that turned out to be expired.** - The case log is checked → It shows who approved it and when; the criterion is fixed instead of blame being guessed at. **Nobody knows what is recorded for each action.** - Checks the log of a real case → You know what you have. **Something is asserted that the log does not support.** - Checks first what is on record → You assert what can be demonstrated. **A client asks what is stored about their activity.** - Explains which fields make up the log → The answer is specific and verifiable. **A specific action is hunted in the history.** - Filters by date, user or file → It is found without walking the whole thing. **There is concern the log could be altered.** - Verifies that entries cannot be edited → The value lies in nobody being able to correct it. --- --- id: KB-TZ-006 url: https://app.codecontract.io/help/traceability-and-compliance/when-someone-asks-you-to-delete-their-data idioma: en categoria: trazabilidad audiencia: administrador nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-003, KB-GL-013] citadoPor: [KB-LE-003, KB-TZ-013, KB-NO-023] --- # When someone asks you to delete their data _What can be deleted, what must be kept, and why that is not a contradiction._ **Responde a:** an employee asks me to delete their data · right to erasure what do i do · delete a supplier's data · can i delete a signed document The request arrives and the instinctive reaction is one of two: delete everything quickly, or delete nothing out of fear. Both are wrong. The right answer separates what must be kept from what there was no reason to hold. ## The three categories | What it is | What to do | | --- | --- | | Data you hold with no current reason | Delete it. It is what the request asks for and what you should not have | | Data with a legal retention obligation | Keep it, and explain why and until when | | Evidence of a signature or delivery | Keep it while the document has effects | > [!IMPORTANT] > A signature is not deleted. This is not a technical limitation: a signature that could be made to disappear at the signer's request would prove nothing, and then no signed document would hold. That gets explained; it is not negotiated. ## What to do, in order 1. **Check who is asking** — That it is the person the data concerns. An erasure request is also an impersonation vector. 2. **Talk to whoever handles data protection** — Someone in your company is responsible for this, even if the title says otherwise. There are deadlines. 3. **Separate the three categories** — With the retention policy in front of you, not from memory. 4. **Reply with reasons** — What was deleted, what is kept and why. A reasoned reply closes nearly every request. > [!WARNING] > If there is a live claim or litigation touching that data, delete nothing without checking. Deleting material relevant to open proceedings is a bigger problem than the one you were solving. > [!NOTE] > The best way to answer these requests well is not to have kept too much. A retention policy genuinely applied turns this into a ten-minute task. **Is this legal advice?** No. It is the practical criterion; the specific deadlines and duties come from your adviser. **How long do I have to respond?** There are legal deadlines and they are short. Which is why step one is telling the right person. **Is my deletion recorded?** Yes, and that helps: it is what shows you honoured the request. ## Ejemplos **A former employee asks for all their data to be deleted.** - The ID copy, held for no reason, is deleted - Their signed contract and payslips are kept, with their legal period - They receive a reply explaining both → The request closes without conflict, and an identity document that was never needed stops being held. **A deletion request arrives and nobody knows where everything sits.** - Locates where that person appears → The request is handled without searching everywhere. **Something is deleted and a copy remains elsewhere.** - Reviews every location before confirming → The deletion is complete. **Something that had to be retained is deleted.** - Checks the policy before deleting → What can be deleted is told from what cannot. **There is no record the request was handled.** - Records the request and what was done → The response is demonstrable. **The request reaches somebody who cannot resolve it.** - Writes down who handles it → The request does not sit waiting. --- --- id: KB-TZ-001 url: https://app.codecontract.io/help/traceability-and-compliance/who-did-what-and-when idioma: en categoria: trazabilidad audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-004, KB-SC-003, KB-CR-004, KB-TZ-021] citadoPor: [KB-TL-009, KB-TZ-003, KB-CO-008, KB-CO-009, KB-DI-005, KB-TZ-011, KB-TZ-016, KB-CR-006, KB-CR-008, KB-AD-001, KB-IN-001, KB-MA-001, KB-IN-002, KB-TZ-002] enLaApp: https://app.codecontract.io/settings/audit --- # Who did what and when _The record that turns a file into evidence, and how to show it to a third party._ **Responde a:** who did what and when on the platform · audit log · how do I prove what happened to a document · public verification of a document · how long are documents retained The difference between a shared folder and this platform is not where the files live: it is that every step is on record. Who asked for what, when the notice went out, when the link was opened, who uploaded the document, who corrected a field and who confirmed it. **En corto** - Every action is recorded with its author and its time. - The record cannot be edited: if it could, it would prove nothing. - A third party can verify a document without an account and without your permission. - Retention is configured per organisation, according to what your sector requires. ## What gets recorded - Sends: to whom, on which channel, at what time, and whether they bounced. - Opens: when each link was opened, which separates "it never arrived" from "they did not look". - Deliveries: which document, who uploaded it and from where. - Automatic readings and manual corrections, with who confirmed each field. - Signatures: who, when, at what level and whether they validated the code. - Changes to the organisation's configuration. ## Why it cannot be edited Same reasoning as in SmartCheck. A record its owner can modify proves nothing to a third party, because the other side can always claim it was changed afterwards. Immutability is what gives it value. ## How to show it to an outsider | You need | You use | | --- | --- | | An auditor to check one specific document | The evidence link or public verification | | To produce a signature in proceedings | The signed PDF and its evidence chain | | To hand over a whole period | The exported folder dossier | | To justify an internal action | The organisation's audit log | > [!NOTE] > What makes evidence strong is that someone who does not trust you can check it. That is why public verification needs neither an account nor your permission. ## How long it is kept It depends on your organisation's retention policy, configured according to what your sector requires. If you need to keep something beyond that on your own terms, download it: a signed PDF is self-contained and validates without depending on the platform. ## Frequently asked questions **Can I see who downloaded a document?** Accesses are logged along with the rest of your organisation's traceability. **What if someone on my team leaves?** Their access is withdrawn, but what they did stays under their name. If it vanished, the history would stop being traceable. **Does it work as evidence in legal proceedings?** What you produce is the signed document with its evidence chain and timestamp, which a third party can verify independently. **Can the log be exported?** Yes. That is what you hand over in an audit, rather than walking someone through screens. ## Ejemplos **A client claims they were never asked for a document that is missing from their file.** - Opens the case and shows the send date and channel - Shows the link was opened two days later - Confirms nothing was delivered and that they were reminded twice → The conversation stops being about who remembers what, because the facts are dated. **Somebody claims they reviewed something and there is no record.** - Checks that action's log → What was done has an author and a time. **A figure appears changed and nobody knows who touched it.** - Checks the figure's own history → The change has a date and someone responsible. **You want to know who granted a third party access.** - Looks up the action in the log → Granting stops being anonymous. **Two people give different accounts of what happened.** - Checks the recorded sequence → The dispute closes by looking. **An auditor asks for evidence of a control.** - Shows the log of real operations → The control moves from assertion to evidence. --- --- id: KB-TZ-002 url: https://app.codecontract.io/help/traceability-and-compliance/proving-a-document-has-not-changed idioma: en categoria: trazabilidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-001, KB-SC-001] citadoPor: [KB-DI-006, KB-SC-004, KB-SC-005, KB-SC-008, KB-TZ-008, KB-NO-001, KB-TZ-009, KB-TZ-010, KB-SC-010, KB-LE-007, KB-TZ-004, KB-TZ-005, KB-GL-005, KB-GL-006, KB-CF-003, KB-CF-008] --- # Proving a document has not changed _How to check it, who can, and why it works without trusting us._ **Responde a:** verify a document is authentic · check whether a pdf was modified · what is a timestamp · verify a document without an account A sealed document can be checked without entering the platform, without an account and without asking our permission. That is the important part: if you had to trust us, it would not prove much. **En corto** - Every document has a fingerprint that changes if a single character changes. - The time is certified by an independent third party, not by our server. - Anyone holding the document can check it. ## How to check 1. **Go to the public verification page.** 2. **Upload the document, or scan its code if it carries one.** 3. **Read the result: it matches or it does not.** ## What each result means | Result | What it means | | --- | --- | | Matches | It is exactly the document that was sealed, on the date stated | | Does not match | The file has changed since then, even by a comma | | Not found | That document was never sealed here | > [!IMPORTANT] > "Does not match" does not necessarily mean fraud. Reprinting a PDF or re-saving it from another program changes the file. What it does mean is that this particular file is not the one that was sealed. ## Why someone else sets the time If we set the date, you would have to trust our clock. It is set by an independent timestamping authority, and its signature can be checked separately. That is the difference between saying "it happened on Tuesday" and being able to prove it. **Do I need an account to verify?** No, and that is deliberate: whoever verifies is usually an outsider. **Will it still work in ten years?** Yes, as long as you keep the document. Verification does not depend on you having an account. **What if I lost the file?** If you are in the organisation, it is stored. If you are a third party, ask whoever sent it. ## Ejemplos **A client suspects the amendment they received is not the one agreed.** - Uploads their copy to the verification page → It matches what was sealed on the signing day, and the suspicion is closed in thirty seconds without argument. **Somebody forwards a document and it must be established it is the same.** - Compares the fingerprint with the registered one → The check does not require reading it through. **Two copies look identical and one has been altered.** - Computes both fingerprints → The original is identified. **A third party wants to verify it themselves.** - Points them to the verification page → They verify without depending on you. **The file was opened and re-saved.** - Checks against the untouched original copy → Verification comes out correct. **You want to prove it without revealing the content.** - Shares only the fingerprint → The proof travels without the document. --- --- id: KB-MA-003 url: https://app.codecontract.io/help/marta/what-the-ai-does-with-my-documents idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-TZ-003] citadoPor: [KB-MA-018, KB-MA-004, KB-MA-005, KB-GL-013] --- # What the AI does with my documents _What gets processed, what never leaves your organisation, and what you can turn off._ **Responde a:** does the ai train on my documents · is it safe to upload confidential documents · turn off artificial intelligence · who can see what my company uploads It is a reasonable question and deserves a straight answer, because what sits in here are contracts, payslips and identity documents belonging to people who did not choose to be here. **En corto** - Your organisation's documents are seen only by your organisation. - Processing is for reading them, not for feeding a general model. - Automatic reading can be switched off per document type. ## What happens when you upload 1. **It is stored** — Encrypted, and tied to your organisation. 2. **It is read, if you have that on** — To extract the values you care about: dates, amounts, identifiers. 3. **It stays put** — The result goes into your case. It is not mixed with anyone else's. ## What you control | Decision | Where | | --- | --- | | Which document types get read and which do not | In each type's configuration | | How long it is kept | In the retention policy | | Who can see it | In permissions and teams | > [!IMPORTANT] > If you hold especially sensitive documents — health data, information about minors, trade secrets — decide expressly whether their type carries automatic reading, rather than leaving the default. It is your decision and it is worth making, not inheriting. > [!WARNING] > Marta answers with what you can see. If a colleague should not see something, they will not see it by asking her either: it inherits permissions, it does not route around them. > [!NOTE] > If one of your own clients asks you this about their documents, the answer is the same and you can show them this page. **Are my documents used to improve the product?** Corrections improve reading of that document type within your organisation. **Can I turn the AI off entirely?** You can disable automatic reading. Documents are stored just the same. **Where is the data hosted?** It is documented in the compliance information; ask if you need the detail for an audit. ## Ejemplos **A client asks their supplier whether their contracts are used to train an AI.** - Shows them this page - Shows that reading is disabled for that document type → The concern is settled with a specific answer rather than a promise. **There is a fear that documents leave the company.** - Checks what is processed and where → The doubt is settled with the fact. **A client asks what is done with their material.** - Explains the processing specifically → The answer is verifiable. **Something sensitive is uploaded without thinking.** - Checks beforehand what is worth processing → The decision is taken knowingly. **It is assumed the AI stores everything it sees.** - Checks what is retained and for how long → Expectations match reality. **An audit about AI use must be answered.** - Checks the invocation log → The answer comes from a record rather than an assertion. --- --- id: KB-MA-007 url: https://app.codecontract.io/help/marta/turning-an-answer-into-work idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-006, KB-MA-004] citadoPor: [KB-MA-015] --- # Turning an answer into work _What to do with the list it just gave you, so it does not stay a curiosity._ **Responde a:** what do i do with the assistant's answer · from answer to action · the assistant gives me data but nothing changes · getting value from ai answers Asking is the easy part and the one that hooks you. The problem shows up three weeks in: you ask, an interesting list appears, you close the screen and nothing happens. An answer that does not end in an action is time spent feeling informed. ## The rule of three exits Every answer should end in one of these three. If it ends in none, the question was badly framed: | Exit | When | What you do | | --- | --- | --- | | A call or a message | Someone specific has to move something | Write to them from the case itself | | A change in the system | A wrong value, a missing expiry, a permission too many | Fix it there and then, not note it down | | A decision to close | Whatever has been dead three months | Close it with its reason | ## The commonest mistake Copying the list somewhere else — a note, an email to yourself — to deal with later. That "later" competes with everything else and loses. If the list has four names, resolve them now; if it has forty, the question was too broad and needs narrowing. > [!WARNING] > If you ask the same thing every week and the same unresolved list keeps appearing, the problem is not the question: nobody has been assigned to resolve it. No assistant fixes that. > [!NOTE] > A question that serves you every week deserves to be a saved filter, not a question. The assistant is for exploring; what repeats belongs one click away. > [!IMPORTANT] > Before acting on a fact with consequences — blocking a supplier, clearing an access — open it and check. The answer got you there in seconds; checking is still faster than having searched. **Can it make the changes for me?** It takes you there; actions that change something you confirm yourself. **What if the list is huge?** Narrow it: a shorter period, one site, one owner. **Does it remember what I already resolved?** The case reflects what you did; the next answer comes out different. ## Ejemplos **A manager asks every Monday what is stuck and copies the list into a notebook.** - Stops copying - Resolves the four cases on the spot, from the case itself → Within a month the Monday list drops from twelve to three, because the ones that never got resolved stop reappearing. **The answer says what is missing and nobody requests it.** - Launches the request from there → The query becomes work done. **The list is copied by hand somewhere else.** - Acts on the files it returns → The copying step disappears. **A gap is spotted and forgotten.** - Turns the finding into a task → What was spotted is not lost. **The same thing is asked weekly and acted on identically.** - Turns the query into a process → The action happens by itself. **The answer flags an error in a figure.** - Corrects the figure from the document itself → The error closes where it started. --- --- id: KB-MA-009 url: https://app.codecontract.io/help/marta/asking-about-several-things-at-once idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-006] citadoPor: [KB-MA-017] --- # Cross-referencing information from different places _What a filter cannot do and a question can._ **Responde a:** cross-reference supplier and site data · ask about several things at once · find information spread across places · the filter does not give me what i need A filter answers a simple question: what meets this condition. When the question crosses two things — which suppliers on this site have something expired and have also gone quiet — the filter falls short and manual work begins. ## The kind of question worth asking | Question | Why a filter cannot give it | | --- | --- | | Which suppliers on this site have something expired and are not responding? | It crosses two conditions and a history | | Which clients have we asked the same thing twice this year? | It needs the pattern, not the status | | Which cases resemble this one that stalled? | It is a comparison, not a filter | | What documentation is missing before we can invoice this client? | It joins things from different places | > [!IMPORTANT] > Before acting on an answer that crosses things, open one of the cases and check. The more elaborate the question, the more pieces where something may be out of date — and the answer sounds equally confident either way. ## How to ask better **En corto** - Name both conditions separately and explicitly. - State the period: "this quarter", not "recently". - And say what you want it for: it changes the shape of the answer. > [!WARNING] > If the answer surprises you a lot, be suspicious before celebrating or panicking. An unexpectedly long list usually means the question was understood more broadly than intended. > [!NOTE] > When a cross-referenced question serves you every month, it deserves to become something fixed. Asking is for exploring; what repeats belongs set up. **Can it cross with data from another of our systems?** Not on its own; that is what the integration is for. **Are complex questions more expensive?** Each query consumes the same; what changes is what it saves you. **What if it finds nothing?** It says so. Finding nothing does not mean nothing exists: the question may not have been the right one. ## Ejemplos **A manager needs to know which subcontractors on a site are incomplete and have gone quiet for three weeks.** - Asks naming both conditions and the period - Opens two of the cases to check → Comes away with four verified names in five minutes, instead of cross-checking two lists by hand. **The figure is in one document and the context in another.** - Asks about both at once → The answer cross-references without opening anything. **Two suppliers' material is compared by hand.** - Asks for the comparison → The cross-reference is immediate. **You want to know which files share a problem.** - Asks about the pattern → The pattern appears without walking them. **The answer crosses data from different periods.** - Specifies the period in the question → The comparison is the one intended. **Information is crossed from files you cannot see.** - Checks the scope before relying on it → The answer is read knowing what it covers. --- --- id: KB-MA-010 url: https://app.codecontract.io/help/marta/the-ten-most-asked-questions idioma: en categoria: marta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-005, KB-TD-001] citadoPor: [KB-MA-014] --- # The ten most asked questions _Copy them as they are: they work with nothing configured._ **Responde a:** example questions for the assistant · what do i ask marta · useful ai questions platform · i do not know what to ask Getting started is hard with a blank screen. These ten work from day one, with no filters configured and nothing learned, and they cover most of what people end up asking. ## To start the day **En corto** - "Which cases have had no movement for over two weeks, and who are they waiting on?" - "What has arrived since yesterday that is waiting for my review?" - "What do I have open right now?" ## To get ahead **En corto** - "Whose mandatory documents expire this quarter?" - "Which suppliers are incomplete and blocked by a single document?" - "Which renewals are due next month?" ## To answer someone **En corto** - "Show me everything for this client over the last year, by date." - "What did we ask this supplier for, and when did they respond?" - "Reconstruct this case's sequence with its dates." - "What documentation is missing before we can invoice this client?" > [!IMPORTANT] > The last three save the most time and are used least, because people assume they have to search by hand. They are exactly the ones that arrive with someone waiting on the phone. ## How to improve them for your case Replace "this client" with the real name and add the period. Everything else works the same. If an answer comes back too long, the question was too broad: narrow by site, by owner or by period. > [!WARNING] > Before acting on any of these answers for something with consequences, open the case and check. They are a shortcut to the fact, not an authority over it. > [!NOTE] > If one of the ten serves you every week, set it up as a saved view. Asking is for exploring; what repeats belongs one click away. **Do they work with nothing configured?** Yes, all ten. **Can I ask them in another language?** Yes. **What if it finds nothing?** It says so. Check you are in the right organisation before concluding it does not exist. ## Ejemplos **Someone starts using the assistant and does not know where to begin.** - Copies the first three as they are → Comes away with an actionable list on day one, without learning any filters. **What is missing is asked and everything is walked by hand.** - Asks about what is outstanding → The list comes out without building it. **Expiries are checked file by file.** - Asks about the period → The review shrinks to reading the answer. **You look for who has not replied.** - Asks who is still outstanding → Only those missing are chased. **You want one specific supplier's status.** - Asks about that supplier → The answer arrives without opening their file. **The same thing is asked every Monday.** - Turns the query into a report → The answer arrives by itself. --- --- id: KB-MA-011 url: https://app.codecontract.io/help/marta/getting-up-to-speed-on-a-file-with-marta idioma: en categoria: marta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-006] citadoPor: [KB-CR-011, KB-MA-017] --- # Getting up to speed on a file with Marta _Picking up someone else's work without reading eighty emails._ **Responde a:** catch up on a file someone else handled · summary of what happened in a process · taking over from a colleague on leave · quickly understand the state of a case It is one of the biggest time sinks and one nobody talks about: someone leaves, goes on sick leave or changes role, and another person has to pick up their files. The norm is spending a morning reconstructing the story. ## The four questions that solve 90% 1. **"Summarise what has happened in this file"** — The sequence, not the detail. Enough to get oriented in two minutes. 2. **"What is outstanding and who is it waiting on?"** — Separates what is yours from what you are waiting for. 3. **"What was promised to this person?"** — What was said by email or message and not yet delivered. 4. **"Is anything expiring soon here?"** — The question that stops you inheriting a problem in week one. > [!IMPORTANT] > The third saves the most grief. Verbal or emailed commitments are the first thing lost in a handover, and the first thing the other party asks about. ## What to verify yourself | Aspect | Why check it yourself | | --- | --- | | Real deadlines | A summary can misquote them; the original rules | | Amounts and terms | Any figure you are going to use gets checked | | Who the contact is | It may have changed without the history saying so | > [!WARNING] > Do not use a summary as the basis for answering a client without opening what was summarised. A summary tells you where to look; it does not replace reading what matters. ## And the reverse: leaving a file behind If you are the one leaving, the best legacy is not a handover document: it is that everything you did lives in the file rather than in your inbox. With that, whoever takes over can ask and get answers; without it, no summary is possible. **En corto** - Conversations in the file, not in a personal inbox. - Commitments written where the next person will see them. - And decisions, with their reasoning, even in one line. > [!NOTE] > Marta answers from what exists in your organisation and what your permissions let you see. If a file was restricted, the summary will not include it either — the same rule as everywhere else on the platform. **Can it summarise several files at once?** Yes, and for a full handover that is usually the first question. **Does it see emails?** Whatever is recorded on the platform. What stayed in a personal inbox, no. **Does it get things wrong?** It can. Anything going to a client is checked against the original. ## Ejemplos **Someone inherits fourteen files from a colleague on leave.** - Asks for a summary and outstanding items across all fourteen - Manually checks dates and amounts on the three most urgent → Starts working the same morning instead of spending two days reconstructing the state. **You must catch up on a months-old file.** - Asks for a status summary → Catching up takes minutes. **Somebody covers for a colleague on leave.** - Asks for a summary of their files → The handover starts informed. **A meeting with a supplier is being prepared.** - Asks what is outstanding with them → The meeting starts with data. **The summary leaves out something important.** - Asks expressly about that point → The answer covers what was needed. **The whole file is read just in case.** - Asks for the summary and opens only what is doubtful → Time goes on what matters. --- --- id: KB-MA-012 url: https://app.codecontract.io/help/marta/marta-cannot-find-something-that-exists idioma: en categoria: marta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-004, KB-MA-002, KB-MA-018] citadoPor: [KB-MA-020] --- # Marta cannot find something that exists _Four reasons, in order of likelihood, and what to do about each._ **Responde a:** marta cannot find a document · the ai says there is nothing but there is · why does it not find what i am looking for · the assistant cannot see my documents You ask about something you know is there and the answer is that there is no record of it. Before assuming a failure, rule out four things, because only the last one really is one. ## The four reasons, by likelihood | Reason | How to check | What to do | | --- | --- | --- | | You lack permission to see it | Search for it manually yourself | Ask an administrator for access | | It is in another organisation | Check which one you are in | Switch organisation | | It was uploaded without reading | Open it and see whether it has text | Reprocess it | | The question pointed elsewhere | Ask using an identifier | Rephrase with a concrete value | > [!IMPORTANT] > The first is by far the commonest and the least like a permissions problem: the answer does not say "you cannot see it", it says there is no record. And that is correct: for your permission level, there is none. ## How to ask so it turns up 1. **With an identifier rather than a name** — A tax ID or case number is not written three different ways. 2. **Saying what it belongs to, not just what you want** — "X's public liability policy" finds better than "X's insurance". 3. **Without the date, at first** — The date you remember is usually off and discards exactly what you want. 4. **And in parts if the question is long** — Two simple questions work better than one with four conditions. > [!WARNING] > If after all that you still cannot find it, search manually before concluding anything. If it does not appear manually either, the problem is not the question: either it was never uploaded, or you cannot see it. ## The case of the silent scan A scanned document uploaded without reading exists but says nothing about itself. It is in the list, it opens, and yet it answers no question about its content. It is the most bewildering case because the document looks perfectly fine on screen. **En corto** - If you can see it manually but it does not answer, it probably was not read. - If you cannot see it manually, it is permissions or organisation. - And if you can see it and the answer is wrong, then it really is the question. > [!NOTE] > Asking consumes, including when the answer is that there is nothing. Ruling out permissions and organisation before rephrasing five times is cheaper and is usually the answer. **Does it learn from my corrections?** It remembers what you explicitly tell it; it does not reinterpret the past on its own. **Can it search another team's documents?** Only if your permissions let you see them. **What if the document is brand new?** It may take a moment to become available after upload. ## Ejemplos **Someone asks about a contract and is told there is no record, although a colleague uploaded it.** - Searches manually and finds nothing either - Requests access from the team that holds it → It appears as soon as they have permission, with nothing to fix. **Something that exists is searched for and does not appear.** - Checks whether you have access to that file → A scope problem is ruled out. **The document was uploaded without processing.** - Checks whether its content is searchable → The document becomes findable. **A field that was never extracted is searched for.** - Adds that field to the extraction → Search finds what is needed. **The question uses a term the document does not.** - Tries the document's own wording → The match appears. **The document sits in another file.** - Widens the question's scope → It is located without walking folders. --- --- id: KB-MA-013 url: https://app.codecontract.io/help/marta/what-marta-does-without-asking-and-what-it-does-not idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-005, KB-CL-007] citadoPor: [KB-MA-016, KB-TL-029] --- # What Marta does without asking and what it does not _The line between looking things up and acting, and who decides where it sits._ **Responde a:** can the ai do things on its own · what actions does the assistant execute · does the assistant send emails by itself · limits of the ai agent The question always comes, and rightly: if the assistant can read everything of yours, what can it do with it? The short answer is that looking things up is one thing and acting is another, and the second is subject to what you decide. ## The three layers | Layer | Examples | Who authorises | | --- | --- | --- | | Consulting | Summarising, searching, comparing, explaining | Your own permissions: it sees what you see | | Preparing | Drafting, building a process, proposing a list | The same, but nothing leaves here | | Acting | Sending, requesting from a third party, closing, approving | Configured, and by default it asks | > [!IMPORTANT] > The first layer is bounded by your permissions, not the assistant's. If you cannot see a file, it does not appear in an answer either: there is no back door through which the AI sees more than you. ## Where to draw the line 1. **Let it consult and prepare, always** — That is where nearly all the time saving is and it can break nothing. 2. **Let it act only on the reversible** — Opening a task, sending a reminder, flagging something for review. 3. **Have it ask on anything going outward** — Anything reaching a third party is better with a person present. 4. **And never on what decides** — Approving, rejecting, blocking a supplier. Someone with a name answers for that. > [!WARNING] > Point three is the one most quickly relaxed "because it's going well", and the one that goes worst when it fails: a wrong message to two hundred suppliers is not undone by a correction. What goes outward deserves a human glance even at thirty seconds' cost. ## What gets recorded **En corto** - Every executed action is in the activity log, marked as done by the assistant. - What it consults leaves a trace too, exactly as if you had opened it. - And what it executes consumes the same: an automatic action costs what a manual one costs. That last point has a practical consequence: a rule firing a thousand times spends a thousand, and it is worth checking the breakdown in the first month it is switched on. > [!NOTE] > You can start with no ability to act and widen it later. That is the recommended path: first check its answers are reliable in your case, and only then let it execute anything. **Can it delete things?** Not something worth delegating, and by default it does not. **Does it learn from our documents?** It uses them to answer you; see the article on what the AI does with your documents. **Can I see what it has done?** Yes, in the activity log, like any user. ## Ejemplos **A company wants the assistant to send reminders and approve simple documentation.** - Lets it handle reminders and tasks - Keeps approval with a person → Recovers the chasing time without delegating any decision it answers for. **It is expected to launch requests unprompted.** - Checks what it does on its own and what it does not → No unrequested actions are assumed. **It is asked to write to a supplier and nobody reviews.** - Reviews the text before sending → What goes out carries your judgement. **It is assumed a figure has been corrected.** - Checks the figure in its document → The real state is known. **It is asked something that requires a decision.** - Takes the decision and uses the answer as support → Each does their own job. **It is expected to act on files it cannot see.** - Checks its scope → Expectations are set. --- --- id: KB-MA-014 url: https://app.codecontract.io/help/marta/the-first-five-questions idioma: en categoria: marta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-PS-011, KB-MA-010] citadoPor: [KB-MA-006] --- # The first five questions _What to ask on day one to find out whether this will help you._ **Responde a:** what should i ask the ai on day one · first questions for the assistant · how to start using marta · examples of useful questions The first time someone sits in front of the assistant they usually ask something generic, get a generic answer, and conclude it is useless. These five questions are chosen for the opposite: they are specific, verifiable, and show what it can do. ## The five 1. **"What expires in the next thirty days?"** — Useful from minute one and checkable at a glance. 2. **"What is waiting on a third party?"** — It shows where work is stuck, which is rarely where you thought. 3. **"Summarise what has happened with [a specific supplier]"** — Pick one you know well: then you can judge whether the summary is good. 4. **"How long do we take on average to close a file?"** — A figure that normally costs half a morning to produce. 5. **"What documents exist for [an identifier]?"** — A tax ID, a registration, an order number. Proof that it finds by content. > [!IMPORTANT] > The third tells you best whether you can rely on it. Asking about something you know by heart, you will see in two seconds whether the summary is right, whether it omits something important, or whether it treats a wrong value as good. ## What not to ask on day one | Question | Why it disappoints | | --- | --- | | "What can you do?" | It answers in the abstract and shows nothing of yours | | Something in a file you cannot see | It will say there is no record, and rightly | | A question with four conditions | Two simple questions work better | | Something you uploaded a second ago | It may take a moment to become available | > [!WARNING] > And do not ask about scanned documents that were never read, expecting answers about their content: they exist, they display, but they say nothing about themselves. If your archive is mostly unprocessed old scans, that shows up right here. ## What to look for in its answers **En corto** - Whether it says where each value comes from. - Whether it distinguishes what is recorded from what it infers. - And whether asking the same thing twice gives the same answer. That last point matters more than it seems: an answer that changes between attempts signals it is at the edge of what it can answer with what exists. > [!NOTE] > Every question consumes, including those that yield nothing. It is not much, but worth knowing before spending an afternoon trying phrasings. **Can I ask in another language?** Yes, and it answers in the one you use. **Can it prepare things?** Yes: drafts, lists, processes. Preparing is different from executing. **Does it see what my colleagues see?** It sees what you see, no more and no less. ## Ejemplos **Someone tries the assistant by asking what it can do and dismisses it.** - Tries the five specific questions - Checks the summary of a supplier they know well → Finds in five minutes two figures that would have cost a morning. **The first question is far too broad.** - Starts with a specific file → The first answer is already useful. **It is tried with a question that has no answer.** - Starts with what is clearly in the documents → The first impression is the right one. **It is dismissed after a poor answer.** - Reformulates more specifically → The second answer changes the view. **The question omits the period.** - Adds the date or the range → The answer points at what was sought. **It is tested with made-up data.** - Tests with a real case → The result says something about your work. --- --- id: KB-MA-015 url: https://app.codecontract.io/help/marta/asking-marta-to-write-for-you idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-007, KB-MA-004] citadoPor: [KB-MA-019] --- # Asking Marta to write for you _A difficult email, a summary for management, a reply to a complaint: what comes out well and what must always be reviewed._ **Responde a:** have the ai write an email · drafting a client reply with ai · summarising for management with ai · ai-generated message template Drafting is one of the things it does best, and also one of the easiest to send without reading. The difference between the two is one minute of reading, and it helps to know when that minute is compulsory. ## What comes out well and what to watch | Task | Usually comes out well | What to check before sending | | --- | --- | --- | | Reminding someone of something outstanding | Yes, and it saves real time | That what is said to be missing is right | | Summarising a file for management | Yes | The figures: a summary can misquote them | | Replying to a complaint | The tone, very well | Everything else: dates, commitments and assumptions | | Drafting a clause or an undertaking | Not the place | That is reviewed by whoever answers for it | > [!IMPORTANT] > The third row holds the real risk and also the biggest saving. A draft reply to a complaint comes out with a better tone than you would manage writing in the heat of the moment — and precisely for that reason it is easy to send without checking whether what it asserts is true. **A well-written text is not a verified text**, and you are the one signing it. ## How to ask so it comes out useful 1. **Say who it is for and what you want to achieve** — "To the supplier, so they deliver this week" gives a different text from "to put it on record". 2. **Say the tone** — Warm, firm, formal. It changes the result most and is asked for least. 3. **And say what NOT to say** — If you do not want to commit to a date or concede something, say so: otherwise it will appear, very politely worded. > [!WARNING] > Point three prevents the most grief in client replies. A friendly draft tends to close with a promise — "you'll have it Friday" — that nobody has checked is achievable. If you did not decide it, it should not be in the email. ## What to do with the draft **En corto** - Read it in full, not diagonally: the errors are usually in a middle sentence. - Check any figure, date or proper name against the file. - And cut what is surplus: drafts tend to run longer than necessary. That last one does more for the reply than any other edit: a five-line message gets answered the same day and a twenty-line one gets left for later. > [!NOTE] > Drafting is an action and consumes, like any AI request. Asking for four versions of the same email to pick a favourite costs four; asking for one and adjusting it yourself usually turns out better. **Can it write in another language?** Yes, and it is where it saves the most time if you rarely write in that language. **Will the recipient know an AI wrote it?** There is no marker; the text is yours from the moment you send it, and so is the responsibility. **Can it use the supplier's history to draft?** Yes, which is why it is worth checking what it cites before sending. ## Ejemplos **Someone asks for a draft reply to a complaint and sends it as is.** - Reads the whole draft and checks dates and commitments - Removes a deadline promise nobody had decided → Replies the same day, in good tone and without committing to a date they could not meet. **A notice is drafted and sent unread.** - Reviews the text before sending → What goes out carries your judgement. **The text uses a tone that is not yours.** - States the tone when asking → The draft resembles how you write. **The draft asserts something not on record.** - Checks the claims before sending → Nothing goes out that cannot be stood behind. **A text is requested with no context.** - States recipient, reason and date → The draft serves almost as it is. **The draft is rewritten from scratch every time.** - Saves the one that worked as a template → The next one takes a minute. --- --- id: KB-MA-016 url: https://app.codecontract.io/help/marta/what-not-to-ask-it idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-004, KB-MA-013] citadoPor: [KB-MA-017] --- # What not to ask it _Questions that look like all the others and where the answer is not worth the same._ **Responde a:** can i ask the ai legal questions · will the ai tell me if this complies · asking the assistant for opinions · limits of what it can answer With a tool that answers almost anything, the hard line is not what it knows: it is which kinds of question its answer is worth as much as it looks. These four are answered as fluently as the rest and should not be used the same way. ## The four | Question | Why it fails | Who to ask | | --- | --- | --- | | "Does this comply?" | It depends on your case, sector and country, and it changes | Your adviser, with the document in front of them | | "Should I accept this contract?" | It is a decision with consequences, not a fact | Whoever answers for that decision in the company | | "What will happen if…?" | Predicting is not reading: there is no fact to look up | Nobody: that is decided, not consulted | | "Is this supplier trustworthy?" | It mixes data with judgement about people | Your own history, read by you | > [!IMPORTANT] > All four share what makes them dangerous: **the answer sounds exactly as confident as when it tells you what expires next week**. There is no visible marker separating a looked-up fact from a constructed opinion, so you have to make that distinction when asking, not expect it in the reply. ## The same question, rephrased to be useful 1. **Instead of "does this comply?", ask what it contains** — "What does this document say about deadlines and penalties?" is lookup-able and useful. 2. **Instead of "should I accept?", ask what to look at** — "Compare it with the previous contract and tell me what changed" prepares the decision without taking it. 3. **Instead of "what will happen?", ask for history** — "How many times was this supplier late last year?" does have an answer. 4. **And instead of judgements, ask for dated facts** — Facts you can show; a judgement you cannot. > [!WARNING] > The case needing most care is the regulatory one, because it tempts most. A reasonable-sounding answer about whether something complies can lead you not to consult and to decide on it — and if it turns out that in your specific case the answer was different, "the assistant said so" covers you with nobody. ## Where it is very good **En corto** - Finding and summarising what already exists in your documents. - Comparing two versions and saying what changed. - Preparing drafts and lists for someone to decide on. - And answering status questions: what is missing, what expires, what is stuck. That is the ground where it genuinely saves hours, and it is much wider than it seems once you get used to asking about facts rather than opinions. > [!NOTE] > Asking consumes, including when the answer is useless. Rephrasing a badly framed question three times costs three; framing it as a factual query first time usually gives a better answer and one action. **What if I insist on asking something legal?** It will answer, and that is precisely why you should be clear what weight to give it. **Can it cite where something came from?** For what is in your documents, yes. For a general opinion, there is no source to cite. **Does more context help?** For factual queries, a lot. For decisions, context was never the problem. ## Ejemplos **Someone asks whether a supplier contract meets what a client requires.** - Rephrases: asks what the contract says on those specific points - Takes that summary and the document to their adviser → The adviser's consultation takes ten minutes instead of an hour, and the decision is taken by whoever should. **It is asked for a decision that belongs to a person.** - Uses the answer as support and decides → Responsibility stays where it should. **It is asked for a legal interpretation.** - Consults the adviser for that → Each question goes to whoever can answer it. **It is asked about something not in the documents.** - Checks whether the information exists → Expectations are set. **It is asked to invent a missing figure.** - Records the gap rather than filling it → What is missing shows as what it is. **It is asked about data from outside the company.** - Checks its scope → The answer is read knowing what it covers. --- --- id: KB-MA-017 url: https://app.codecontract.io/help/marta/asking-live-during-a-meeting idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-011, KB-MA-016, KB-MA-009] citadoPor: [KB-MA-019] --- # Asking live during a meeting _Looking things up while someone waits changes what to ask and what to say out loud._ **Responde a:** look up data during a client call · finding information in a meeting · answering an auditor live · using the ai while talking to someone One of the things that most impresses in a call is answering on the spot something that normally requires "let me check and get back to you". You can, and there are two or three precautions that separate looking good from looking bad in front of whoever is on the other end. ## What to ask live and what not | Yes, live | Better afterwards | | --- | --- | | What is this supplier missing? | Does this meet what the client requires? | | When was it sent and what did they reply? | How much has this account cost us? | | What expires for this company this quarter? | Should we accept this condition? | | What happened last time with this order? | Any figure going into a contract | > [!IMPORTANT] > The right column is not about it being unable to answer: it is that **an answer said out loud in front of a third party becomes a commitment**. If you quote an amount or assert compliance in a meeting and the nuance turns out to be different, you have already said it — and correcting afterwards costs far more than having said "let me confirm and write to you". ## How to ask when you are in a hurry 1. **With the identifier in front of you** — The tax ID, order number or exact name: live, there is no time to rephrase three times. 2. **One thing at a time** — Two short questions are answered sooner than one with four conditions. 3. **And separating what is recorded from what you infer** — "It shows delivered on the 4th" is a fact; "so they already have it" is your conclusion. > [!WARNING] > The nuance that avoids the bad moment: **before saying a figure out loud, check where it comes from**. If it was looked up — a date, a status, a send — say it with confidence. If it is a summary or a comparison, say it as such: "I'm getting…, I'll confirm in writing". The other side cannot tell the difference when they hear it, but they will remember if it later does not match. ## Where it pays off most **En corto** - In a call with a supplier claiming they already sent something. - During an audit visit, to locate a specific file without keeping anyone waiting. - In an internal meeting, so you do not leave with five things "to check". - And in a negotiation, to arrive with the history rather than with memory. The last changes outcomes most: going into a renegotiation knowing how many incidents there were last year is a different conversation from going in with a feeling that there were a few. > [!NOTE] > Every query is an action and consumes, including those made mid-call. It is little and usually worth it; what does not pay is rephrasing the same question five times live because the identifier was not ready. **Can I show the answer on screen to the client?** Careful: it may contain other parties' data. Better to read out what is needed. **What if it answers something that clashes with what I know?** Trust your knowledge and check afterwards: live, do not argue with the tool. **Is it useful during an inspection?** For locating things fast, yes. To assert compliance, answer with the document in front of you. ## Ejemplos **A supplier calls saying they sent a certificate the company does not have.** - They check the send status and what was received, live - They state what is recorded, without over-concluding → The call ends with the fact on the table instead of an "I'll check and get back to you". **A figure is needed in a meeting and nobody has it.** - Asks there and then → The meeting is not postponed over a figure. **It is answered from memory and turns out to be another.** - Checks before asserting → What is said is true. **The live question is too broad.** - Narrows it to the file or the period → The answer arrives in time. **The screen with the answer is shared.** - Checks what else is visible before sharing → Nothing extra is shown. **After the meeting there is no record of what was consulted.** - Records the decisions in the file → The meeting leaves a trail. --- --- id: KB-MA-018 url: https://app.codecontract.io/help/marta/how-far-what-marta-sees-reaches idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-003, KB-MA-008, KB-MA-020] citadoPor: [KB-MA-012] --- # How far what Marta sees reaches _It searches your organisation's material, not your user's. The difference matters more than it looks._ **Responde a:** can marta see every document · can it see a document that is not mine · do permissions affect what it answers · what is the assistant's scope It is the first question anyone with responsibility asks: how far does it reach. And the answer matters because it is not the intuitive one — people assume it answers with «your stuff», when in fact it searches the organisation's. ## Where the limits really are | Limit | Exists | What it means | | --- | --- | --- | | Your organisation | Yes, and it is the hard limit | It does not reach another company's, even with a shared supplier | | Whatever is inside the organisation | That is where it searches | Including material that person would not open on their own | | What you make up in the question | It does not fill in | If it is not stored, it does not know it | | What was deleted | Out of reach | What was withdrawn does not come back by asking | > [!IMPORTANT] > That second point is the one to settle before opening it to the whole team: **asking is a way of searching, and it searches the organisation as a whole**. If some material should not be within everyone's reach, the control is where it lives and who has access to that part — not the hope that nobody asks about it. It is exactly the criterion you apply to a shared folder, applied to a conversation. ## What you do about it, in practice **En corto** - Decide where sensitive material lives before opening the assistant to the team. - And do not use «nobody knows about it» as access control: it never was. - What does depend on the person: what they can do with what they find. - Searching and acting are different things, and the second carries its own permissions. > [!WARNING] > There is another reach that surprises more, and it is that of instructions: **what is saved «for the whole organisation» changes other people's answers**. If someone states that reports should always follow a particular criterion, that applies too to whoever asks tomorrow without knowing the instruction exists. It is not a fault — it is what lets the assistant work the way the house works — but those instructions deserve an owner and a review, like any other shared setting. ## How to check it for yourselves 1. **Ask about something that only sits in one specific folder** — Whether it turns up tells you more than any explanation. 2. **Repeat the test with a lower-permission user** — That shows where the real line sits in your account. 3. **And review which instructions are saved for everyone** — They pile up without anyone rereading them. > [!NOTE] > What gets processed, what leaves your organisation and what can be switched off is a separate conversation, explained elsewhere. This is only about the reach of the search. **Can it see another organisation's material?** No. That is the line that is not crossed. **What if I delete a document?** It stops being available to answer with. **Is there a record of what it is asked?** Yes, and it is worth knowing before asking anything. ## Ejemplos **A company wants to open the assistant to the whole team and hesitates over HR documents.** - Moves them to a restricted area first, then checks by asking → The reach of the answers matches the access it had already decided, not luck. **A file you have no access to is asked about.** - Checks the scope before relying on it → The answer is read knowing what it covers. **The answer looks incomplete.** - Checks which files it can see → The omission is explained. **It is expected to see documents from another organisation.** - Checks which one the question is coming from → The confusion clears. **A user sees more than they should in an answer.** - Reviews their permissions → The scope matches the role. **An answer is shared with somebody outside.** - Checks what information it contains → No more goes out than should. --- --- id: KB-MA-019 url: https://app.codecontract.io/help/marta/when-an-answer-leaves-the-company idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-004, KB-MA-015, KB-MA-017] citadoPor: [KB-MA-020] --- # When an answer leaves the company _Asking internally and pasting the answer into an email to a client are two very different things._ **Responde a:** can I send a client what the AI answers · using an assistant answer in a report · who is liable for what the AI writes · quoting figures the assistant gave me You ask how many of a client's files are still open, a flawless summary appears, and the natural move is to copy it and send it. At that moment something worth keeping in mind happens: the answer stops being an internal query and becomes a statement of yours. ## What changes when it crosses the door | Inside | Outside | | --- | --- | | It helps you get your bearings | It reads as a commitment | | An error is fixed and forgotten | An error has to be corrected in front of the client | | It is a summary of what is stored | It looks like a company statement | | Nobody checks the figures twice | Whoever receives it keeps the figure | > [!IMPORTANT] > The part that cannot be delegated: **what you send is yours from the moment you hit send, and it carries no mark of how it was drafted**. Nobody on the other side knows — or needs to know — whether a person wrote it or it came from a query. So a figure about to leave the company gets checked against its record first: not because the answer usually fails, but because you answer for it, and a misquoted number does not cost the same outside as it does inside. ## What to check before sending 1. **Figures and dates, in their place** — They are what the other side keeps, and will quote later. 2. **That nothing from another client slipped in** — A summary can draw on several places at once. 3. **That it does not promise what you do not want to promise** — A friendly text can commit to dates on its own. 4. **And the tone, which reads differently outside** — What sounds direct internally can sound curt outside. > [!WARNING] > One case slips through easily and is not obvious: **a summary does not always separate what is confirmed from what was pending**. If a file holds a document that was submitted but not reviewed, a summary may treat it as good without the caveat — and that caveat is exactly what matters when the reader is a client awaiting confirmation. Before sending a status, check whether what you call «there» is what is settled or merely what arrived. ## When not to forward anything **En corto** - If it is going into proceedings or a claim: that is drafted by whoever answers for it. - If the client is waiting on a position rather than a figure. - And if you could not yourself defend where each number comes from. > [!NOTE] > This is not distrust of the tool: it is the same rule you would apply to a draft handed to you by a colleague. The draft is welcome, and you sign it after reading it. **Can I say the AI drafted it?** You can, and it does not change who answers for what it says. **What about an internal summary?** No ceremony needed there: that is exactly what it is for. **Is it worth asking for sources?** Yes, and checking two: that is what makes reviewing quick. ## Ejemplos **A company forwards a status summary to a client without checking it.** - Checks the figures and whether what was submitted had been reviewed → The client gets a status that holds up, not a confirmation of something still under review. **An answer is copied verbatim to a client.** - Reviews the text before sending → What goes out carries your judgement. **The answer includes another client's data.** - Checks what it contains before forwarding → Information does not cross between clients. **Something is asserted to a third party unchecked.** - Cross-checks against the original document → What is asserted holds up. **The tone does not fit the relationship.** - Adjusts the text before sending → The message sounds like you. **There is no record of what was sent.** - Records the send in the file → What was communicated leaves a trail. --- --- id: KB-MA-020 url: https://app.codecontract.io/help/marta/when-the-answer-starts-from-bad-data idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-004, KB-DI-005, KB-MA-012, KB-MA-019] citadoPor: [KB-MA-018] --- # When the answer starts from bad data _An answer can be perfectly reasoned and false, because the value it started from was misread._ **Responde a:** marta gave me the wrong date · the answer does not match the document · the assistant gives incorrect data · why does it quote an amount that is wrong You ask when a certificate expires and get a date. The date is wrong, but not because it was invented: it is the one on record, and that one was stored wrong the day the document was read. The answer is faithful to what is there; what is there is what fails. ## Two failures that look alike and are fixed differently | Symptom | Where it comes from | How it is fixed | | --- | --- | --- | | It says something that exists nowhere | It filled a gap | Ask for the source and check | | It says a stored value, but a wrong one | It was misread from the document | Fix the value on its record, not the answer | | It says an old value | There is a newer version unrecorded | Register the new version | | It cannot find something that exists | Out of reach or badly named | A different problem with a different fix | > [!IMPORTANT] > The second row is the most deceptive, for one specific reason: **if the value is stored wrong, the answer will be coherent, confident and wrong — and asking again gives the same result**. Rephrasing the question does not expose it; only opening the document does. So when a figure or a date will have consequences, the check is not rereading the answer: it is looking at the paper it came from. ## How to catch it early 1. **Ask where it comes from before using it** — A value with a document behind it is checked in ten seconds. 2. **Distrust anything that sounds too neat** — First-of-the-month dates, round amounts: the readings that fail most. 3. **And cross-check against something you know** — If the supplier invoices monthly, an annual figure jars by itself. > [!WARNING] > What to do on finding one, and almost nobody does: **fix it at source, not only in the email you were writing**. Correct the figure in the message to the client while the stored value stays wrong and it will surface again tomorrow — in a report, in an expiry alert, or in the answer given to a colleague. A misread value does not bother you once: it bothers you every time anyone asks, always with the same confidence. ## What reduces these cases at the root **En corto** - Check the values on important documents when uploading, not when using them. - Extract only what you will actually consult: fewer values, fewer inherited errors. - And treat the first use of a value as the review that never happened. > [!NOTE] > This is not specific to the assistant: any report, alert or dashboard using that value gives the same result. The difference is that an answer written in plain language sounds more convincing, and so gets checked less. **Can I ask it to check the document?** It can cite where the value comes from; checking the paper says so is yours. **What if the document is wrong, not the reading?** Then it is the issuer's problem: ask for a correction and record it. **Is it worth reviewing old values?** Those in use, yes; start with the ones driving an expiry date. ## Ejemplos **A company sends a client an expiry date that turned out to be misread.** - Fixes the value on the document record, not only in the email → The renewal alert lands when it should and nobody else receives the wrong date. **The answer rests on a misread figure.** - Corrects the figure in its document → The next answer is already right. **The error is corrected in the answer, not at source.** - Corrects it where the figure originated → The error does not return tomorrow. **An odd figure is spotted and ignored.** - Checks the original document → The error closes on detection. **The same bad figure affects several answers.** - Corrects the source and asks again → Every answer is fixed at once. **A decision is taken on an answer built from a bad figure.** - Checks the source before deciding → The decision rests on what is true. --- --- id: KB-MA-008 url: https://app.codecontract.io/help/marta/what-marta-remembers-about-you idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-004] citadoPor: [KB-MA-018] --- # What it remembers from one time to the next _It can store things about how you work. What is worth remembering and what is not._ **Responde a:** does marta remember what i tell it · ai assistant memory · delete what the ai stored · personalise the assistant to how we work The assistant can carry things from one conversation to the next: what you call things, which suppliers are critical, what criteria you use to approve. That makes it more accurate the second time, and it also means deciding what gets stored. ## What is worth remembering | Yes | No | | --- | --- | | Your vocabulary: what you call each thing | Data already held in a case | | Stable criteria: what you treat as blocking | Anything about specific people on your team | | How you prefer information presented | Passwords or credentials, never | > [!IMPORTANT] > Do not ask it to remember credentials or third parties' personal data. The assistant's memory is not the place: credentials belong in access keys, and people's data in their case with its permissions. ## What is worth reviewing What is stored can be viewed and deleted. It deserves a review when something fundamental changes — an approval criterion, how you organise — because the assistant will keep applying the old one until told. > [!WARNING] > If someone teaches it a wrong criterion, it will apply it until someone corrects it. Memory accelerates the good and the bad equally. > [!NOTE] > What it remembers belongs to your organisation, not to you personally. If two people on the team work differently, what it learns from one it applies with the other. **Can I see what it stored?** Yes, and delete it. **Does it share with other organisations?** No. It belongs to yours. **Can I switch it off?** Ask if you prefer it to keep nothing between conversations. ## Ejemplos **A team changes its approval criterion and the assistant keeps applying the old one.** - Reviews what is stored and deletes the old criterion → It is accurate again on the next query, without having to repeat the context each time. **The context is repeated in every question.** - Builds on what has already been said in the conversation → Questions get shorter. **It is expected to remember something from last week.** - Checks what is retained between sessions → Expectations are set. **The file changes and it keeps talking about the previous one.** - States the file when changing subject → The answer points at what is being asked. **You want to pick up yesterday's query.** - Gives the minimum context again → The conversation resumes without detours. **A conversation is shared with a colleague.** - Checks what information it contains first → No more is shared than should be. --- --- id: KB-MA-004 url: https://app.codecontract.io/help/marta/when-not-to-trust-the-answer idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-003] citadoPor: [KB-MA-007, KB-CL-004, KB-MA-012, KB-MA-015, KB-MA-016, KB-MA-019, KB-MA-020, KB-MA-008, KB-MA-006] --- # When not to trust the answer _Where it is right, where to check, and why that does not make it useless._ **Responde a:** does the ai assistant make mistakes · can i trust what marta says · the ai gave me a wrong figure · verify the assistant's answer An assistant that answers in seconds across hundreds of cases is useful precisely because it is fast. What you need to know is where that speed is paid for, so you check there and not everywhere. ## Where it is right and where to check | Kind of question | Reliability | What to do | | --- | --- | --- | | "Which cases are stuck?" | High: it is a filter | Use it | | "Whose insurance is expiring?" | High, if the dates are set correctly | Use it | | "Summarise what happened on this case" | Good for orientation | Read the case before deciding | | "How much do we owe this supplier?" | Depends on that data being here | Check it in your own system | > [!IMPORTANT] > Before a decision with consequences — a payment, granting site access, closing a case — check the fact at source. The assistant takes you there in seconds; that is its job, not to replace the check. ## Why it sometimes falls short **En corto** - It only knows what is here: what was agreed by phone is not. - A misread value in a document will be repeated as is: it does not invent it, but it carries it along. - If the question is ambiguous, so is the answer. > [!NOTE] > Asking with a specific timeframe and subject removes most misunderstandings. "What is missing?" is a bad question; "what does Muñoz Engineering still need to start on site?" is a good one. > [!WARNING] > If it gives you a figure that surprises you, neither dismiss it nor assume it: open it. There is almost always something real behind it — an expired document, a case nobody was watching — even if the reading was not exact. **Does it invent data?** If it cannot find something, it says so rather than filling it in. **Can it see what I cannot?** No. It inherits your permissions. **Is it worth it if I have to check?** Checking a fact it took two seconds to find is still far faster than hunting for it. ## Ejemplos **The assistant says a supplier's insurance lapsed two months ago.** - The document is opened - The date had been misread: it expires next month → The value is corrected, the alert repositions, and the check was still worth it because nobody had looked. **The answer sounds confident and is wrong.** - Checks which documents it comes from → Verification is one click. **The answer is used for an important decision.** - Cross-checks against the original document → The decision rests on the source. **The answer rests on a misread figure.** - Corrects the figure in its document → The next answer is already right. **Something outside the scope is asked.** - Checks which files it can see → It becomes clear why the answer is partial. **The answer is copied verbatim to a client.** - Reviews the text before sending → What goes out carries your judgement. --- --- id: KB-MA-005 url: https://app.codecontract.io/help/marta/who-marta-is idioma: en categoria: marta audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-003, KB-TL-029] citadoPor: [KB-MA-010, KB-MA-013] --- # Who Marta is _The platform's assistant: what it does, what it does not, and where to start._ **Responde a:** what is marta · what the platform assistant is for · how do i start using the ai · can marta do things for me Marta is the platform's assistant. It lets you ask in plain language what you would otherwise have to find by filtering, and it answers from what is in your organisation: your cases, your documents, your dates. **En corto** - It answers from your data, not from general internet knowledge. - It sees only what you can see: it inherits your permissions. - It takes you to the place; decisions and changes are yours. ## Where to start The first useful question is nearly always the same: "what is stuck?". It returns something actionable on day one, with nothing configured. - "Which cases have had no movement for over two weeks?" - "Whose documents expire this quarter?" - "Who has not yet signed the May amendment?" ## What it does not do - It does not know what is not here: what you agreed by phone is not. - It gives no legal opinions and will not tell you whether a contract is good for you. - It changes nothing without your confirmation. > [!NOTE] > Pin down the timeframe and the subject and the answer improves a lot. "What is missing?" returns something useless; "what does Muñoz Engineering still need to start on site?" returns a list you can work from. > [!WARNING] > Before a decision with consequences, check the fact at source. Marta gets you there in seconds: that is its job, not to replace the check. **Does it see other teams' documents?** Only if you do. **Is what I ask stored?** Queries are logged, like any access to data. **Does it need switching on?** It is in the platform. If you prefer not to use it, you need do nothing. ## Ejemplos **Someone new to the platform does not know what to look at first.** - Asks which cases have been stuck for over two weeks → Comes away with six specific names on day one, without having learned any filters. **It is expected to decide for you.** - Uses it to gather, not to decide → The decision stays yours. **Questions assume it knows what is not written down.** - Checks what information it has in front of it → Expectations are set. **It is expected to act unprompted.** - Checks what it does on its own and what it does not → No unrequested actions are assumed. **It is asked something that belongs to a person.** - Reserves judgement calls for people → Each does their own job. **It is used once and dropped.** - Tries it on the questions that repeat → The saving appears where there is repetition. --- --- id: KB-MA-006 url: https://app.codecontract.io/help/marta/questions-that-save-you-a-morning idioma: en categoria: marta audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-002, KB-MA-004, KB-MA-014] citadoPor: [KB-MA-007, KB-MA-009, KB-MA-011] --- # Questions that save you a morning _The ones that return something actionable, with their exact shape._ **Responde a:** example questions for the assistant · how to ask the ai better · get reports by asking · what can i ask marta The difference between a question that returns a list of names and one that returns a useless paragraph is three things: the subject, the timeframe, and what you intend to do with the answer. ## The shape that works **Specific subject + timeframe + purpose.** "Which suppliers on the Getafe site have something expired or expiring this quarter, and what are they missing?" returns a list you can phone from. "How are things going?" does not. ## The highest-yield ones, by moment | When | What to ask | | --- | --- | | Monday morning | "Which cases have had no movement for over two weeks, and who are they waiting on?" | | Before a client meeting | "Show me everything for this client over the last year, by date" | | Before an audit | "Which cases on this site are incomplete, and what exactly is missing?" | | At month end | "What was signed this month and what was left unsigned?" | | When a dispute arrives | "Reconstruct this case's sequence with its dates" | ## Two tricks - Chain it: ask, look at the answer, refine on top of it. That beats trying to phrase the perfect question first time. - Ask for the format you need: "as a list with name and date" saves you reordering it yourself. > [!WARNING] > Whatever it returns for a decision with consequences, check it at source. It got you to the fact in two seconds: checking is still far faster than having searched. > [!NOTE] > If a question serves you every week, that is a filter worth saving. The assistant is for exploring; what repeats belongs one click away. **Can I ask it to draft an email?** It can help with the wording, but you launch the send. **Does it understand long questions?** Yes, and they usually work better than short vague ones. **Can I ask in another language?** Yes. ## Ejemplos **A manager spends an hour every Monday reviewing cases one by one.** - Asks what has been stuck over two weeks and who it is waiting on → The hour becomes five minutes and a list of four calls. **A hundred files are walked to see what is missing.** - Asks what is outstanding and from whom → The morning is recovered. **A figure is hunted across twenty documents.** - Asks for the figure and its source → You get there in a minute. **A meeting is prepared by reading a whole file.** - Asks for a status summary → Preparation takes five minutes. **You want to know what expires this month.** - Asks for the period's expiries → The list comes out without building it. **Two periods are compared by hand.** - Asks for the difference between them → The comparison is immediate. --- --- id: KB-MA-001 url: https://app.codecontract.io/help/marta/what-is-marta idioma: en categoria: marta audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-001, KB-PS-001, KB-TZ-001] citadoPor: [KB-MA-002] enLaApp: https://app.codecontract.io/marta --- # Marta, the AI assistant _What she knows about your organisation, what she can do for you and where the limit is._ **Responde a:** what is marta · the platform's ai assistant · can I ask the ai about my cases · what does marta know about my organisation · can the ai do things for me Marta is an assistant that works on what is already in your organisation: your cases, your documents, your contacts. The difference from a generic assistant is that she does not answer from memory: she answers by looking at your data, and only the part you are allowed to see. **En corto** - She sees only what your user sees: no permission jumping, no crossing organisations. - She is for asking and for doing, not only for chatting. - What she does is logged exactly as if you had done it yourself. - She does not decide anything with consequences: she proposes and you confirm. ## What she is actually for - Finding something without remembering where it was: "the contract we signed with Gómez Workshops". - Summarising status: "which cases have been stuck for more than a week". - Preparing work: describe a process in plain language and she builds it for you to review. - Answering how-to questions without leaving the platform. ## What she does not do She does not see what your user cannot see, nor data from another organisation. She does not sign for you or close a case on her own. And she does not invent: if something is not in your data, she says so rather than filling it in. > [!NOTE] > Actions she takes appear in the log with a record that they went through her, just like any other. Traceability does not change because you used the assistant. ## How to ask well | Instead of | Try | | --- | --- | | "find me the contract" | "the rental contract we signed with Ruiz in March" | | "how is everything going" | "which supplier onboarding cases are incomplete" | | "make a process" | "a process to ask suppliers for their tax ID, insurance and clearance certificate" | _The more specific the question, the fewer rounds — exactly as when asking a person._ ## Frequently asked questions **Can she see another department's documents?** Only if your user can. Permissions are the same as browsing by hand. **Are models trained on my documents?** Your organisation's data is used to answer you. If you need the contractual detail of how it is processed, it is in the legal documentation and the trust centre. **Does asking her consume credits?** AI queries have a cost, like automatic reading. It shows up in the consumption history. **Can she be wrong?** Yes, like any assistant. That is why what she proposes gets reviewed before you confirm, exactly like a field read from a document. ## Ejemplos **Someone needs to know which supplier onboardings have been open more than two weeks and does not know how to filter.** - Asks Marta directly, in those words - Gets the list with what is missing on each - Asks her to resend the reminder to those who have not delivered → Ten minutes of filtering turned into one question, and the reminder goes out with a record of who asked for it. **A manual search runs across twenty files.** - Asks and lets it assemble the answer → The search goes from a morning to a minute. **Something is asked that the answer cannot know.** - Checks how far what it sees extends → Expectations are set beforehand. **The answer is taken as final.** - Checks which documents it comes from → The answer can be verified. **The question is asked in an ambiguous phrase.** - Narrows it to the file or the period → The answer points at what was sought. **It is used to draft something that goes outside.** - Reviews the text before sending → What goes out carries your judgement. --- --- id: KB-MA-002 url: https://app.codecontract.io/help/marta/what-to-ask-marta idioma: en categoria: marta audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-MA-001, KB-TL-008] citadoPor: [KB-ET-006, KB-MA-003, KB-MA-009, KB-MA-011, KB-MA-012, KB-MA-014, KB-IN-010, KB-MA-008, KB-MA-004, KB-MA-005, KB-MA-006] --- # What to ask Marta _The questions it answers well, the ones it does not, and why._ **Responde a:** how to use the marta assistant · what can i ask the ai · marta does not understand me · search using the assistant Marta answers about what is in your organisation: your cases, your documents, your dates. It knows nothing that is not there, and that is an advantage — what it tells you comes from your data, not from a guess. **En corto** - Ask for what you want to know, not for where it might be. - It sees only what you can see: it will not show what is not yours. - If it does not know, it says so instead of inventing. ## Questions it answers well - "Which cases have been stuck for more than two weeks?" - "Which suppliers have insurance expiring this quarter?" - "Who has not signed the May amendment?" - "Show me what this subcontractor delivered last year." ## Questions it does not - Anything not on the platform: it does not know what you agreed by phone. - Legal opinions: it will not tell you whether a contract is good for you. - Predictions: it does not know whether that supplier will deliver on time. > [!WARNING] > Check what it tells you when the decision matters. It is a fast route to the data, not an authority over it. ## How to ask better Pin down the timeframe and the subject. "What is missing?" gives a useless answer; "what does the Muñoz subcontractor still need in order to start on site?" gives an actionable list. **Does it see other teams' documents?** Only if you do. It inherits your permissions, it does not widen them. **Is what I ask stored?** Queries are logged, like any access to data. **Can it do things or only answer?** It answers and takes you there. Actions that change something you confirm yourself. ## Ejemplos **A manager wants to know what is stuck before Monday's meeting.** - Asks which cases have had no movement for over two weeks → Arrives with a list of six names instead of a vague sense that things are stuck. **Something far too general is asked.** - Narrows it to the file, period or supplier → The answer is usable. **A field that was never extracted is asked about.** - Checks whether that field exists → You learn whether the data or the question is missing. **The same question is asked every week.** - Turns the query into a report → The answer arrives by itself. **Something outside the scope is asked.** - Checks which files it can see → Expectations are set. **Three questions are chained into one.** - Asks them one at a time → Each answer is clear. --- --- id: KB-TD-001 url: https://app.codecontract.io/help/day-to-day/where-to-start-each-morning idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-002, KB-TL-008, KB-TD-013] citadoPor: [KB-TD-002, KB-TD-003, KB-TD-006, KB-TD-008, KB-MA-010, KB-TD-011, KB-TD-015, KB-TD-018, KB-TD-020, KB-TD-004] --- # Where to start each morning _Five minutes that order the day, in the order that works._ **Responde a:** what do i look at first · how do i organise my day on the platform · where to start each day · daily working routine Signing in and browsing "to see what there is" is the fastest way to lose half an hour without closing anything. This order does the opposite: urgent first, what someone is waiting on next, and your own work last. ## The order that works 1. **What has arrived** — What was delivered or signed since yesterday. Approving or rejecting on the spot stops it piling up. 2. **What is blocking you** — What cannot move without you. It is usually little and usually quick. 3. **What is stuck** — Filter by age, not by count. Two or three calls achieve more than twenty emails. 4. **Your own work** — What you start yourself. It goes last deliberately: start here and the rest never happens. | When | What you look at | How long | | --- | --- | --- | | On signing in | What arrived since yesterday | Five minutes | | Monday | Anything stuck over two weeks | Half an hour | | Month end | What expires next month | Ten minutes | > [!IMPORTANT] > Approving or rejecting the moment something arrives saves the most time over the long run. A document reviewed today costs a minute; the same document three weeks later costs reconstructing what it was about. > [!WARNING] > Do not start with what has been stuck longest. It weighs the most and moves the least, and burns the half hour before you have touched anything urgent. > [!NOTE] > If you do not know what to look at on signing in, ask the assistant what is stuck. It returns something actionable with no filters configured. **Can I see only my own?** Yes, by filtering on owner. **Will it alert me if something urgent arrives?** Alerts are configurable; keep few and make them matter. **What if I have hundreds of cases?** Then order matters more, not less: always filter before looking. ## Ejemplos **Someone signs in each morning and browses until something demands attention.** - Adopts the order: arrived, blocking, stuck, own → Closes in twenty minutes what used to eat the morning in fragments. **Every morning the twenty-three active files are opened to see which moved.** - Filters by what is waiting on your side - Lets the rest run untouched - Reviews separately, once a week, what has been stalled too long → The daily review goes from half an hour to two minutes, and nothing is lost. **The day starts with whatever landed in the inbox.** - Starts with what is blocking somebody else → The work that unblocks goes out first. **Everything is reviewed and nothing is closed.** - Closes what is only awaiting confirmation → The list goes down instead of repeating. **The urgent gets handled and the important never arrives.** - Reserves a fixed slot for what expires in weeks → What expires stops turning into urgent. **Nobody knows what is waiting on whom.** - Separates what waits inside from what waits outside → Each list has a different action. --- --- id: KB-TD-002 url: https://app.codecontract.io/help/day-to-day/setting-up-alerts-that-actually-help idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-CC-002, KB-TD-020] citadoPor: [KB-TD-001, KB-TD-009, KB-TZ-014, KB-TD-004] --- # Making alerts worth reading _Too many alerts is the same as none: people stop reading them._ **Responde a:** configure notifications · i get too many alerts · i miss the important things · turn off notifications The system can alert you about almost anything, and that is the problem. An inbox with forty alerts a day becomes noise within a week, and from that moment the one that mattered is lost too. ## The rule **Alert only on what you will act on that day.** Everything else gets looked at when it is time, not when it happens. | Event | Alert? | Why | | --- | --- | --- | | Someone rejects a document | Yes | It needs you to do something | | A case you were waiting on completes | Yes | It unblocks work | | Something expires in 30 days | Yes | There is time to act | | Someone opens a notice | No | It is information, not a task | | The twenty-first document is delivered | No | It is reviewed together at the end | > [!IMPORTANT] > If an alert does not end in you doing something, it should not be an alert. It should be something you consult when you decide to look. ## The two settings that change most **En corto** - Grouping: one daily digest instead of one alert per event. - By owner: yours reach you, not the whole team's. > [!WARNING] > Be careful turning them all off out of frustration. What usually follows is a missed expiry, then everything gets switched back on and the noise returns. The middle ground is what lasts. > [!NOTE] > If you receive alerts about things that are not yours, the problem is not the alerts: it is permissions or how ownership is assigned. **Can settings differ per module?** Yes, and they usually need to: a signature is not an upload. **Can they arrive on another channel?** Ask, depending on what you have configured. **Do I lose information if I turn them off?** No. Everything stays in its case; you only stop getting the nudge. ## Ejemplos **Someone receives 60 alerts a day and has stopped reading them.** - Keeps only rejections, completed cases and 30-day expiries - Groups the rest into a daily digest → Drops to five or six a day, and starts opening them again. **Forty notifications arrive a day and the team has stopped opening them.** - Leaves on only those requiring an action - Groups the informational ones into a digest - Reviews at three months which are still ignored → A notification means again that there is something to do. **The notification goes to the whole team and nobody takes it on.** - Addresses each one to an owner → Somebody is on the hook. **The notification does not say what to do.** - Includes the specific action in the notice itself → You act without opening three screens. **Notifications go to an address nobody watches.** - Directs them to a monitored mailbox → The notification gets read. **An important notice is lost among twenty routine ones.** - Separates what requires action from what only informs → The important one stands out. --- --- id: KB-TD-003 url: https://app.codecontract.io/help/day-to-day/tasks-and-reminders idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-CF-005] citadoPor: [KB-TD-006, KB-CL-005] --- # Tasks: what the system will not do for you _For what depends on a person rather than a document._ **Responde a:** create a task · reminder to call a supplier · assign work to a colleague · so i do not forget to do something The platform chases documents on its own. What it cannot do is make a phone call, negotiate a deadline, or decide whether a supplier is still worth keeping. Those are tasks, and unwritten tasks get forgotten. ## What deserves to be a task | Yes | No | | --- | --- | | Phone the supplier who has not opened the notice in a month | Remember to request a document (the process does that) | | Review approval criteria with the team | Remember something expires (the alert does that) | | Decide whether to close a dead case | Check whether someone signed (the case shows it) | _If the system can do it or warn you, do not make it a task: it will duplicate what already works._ ## The three things that make a task get done **En corto** - A concrete verb: "phone", not "Muñoz matter". - One person, not a team. What belongs to everyone gets done by nobody. - A real date, not "as soon as possible". > [!WARNING] > A task list that grows and never shrinks stops being read, exactly like a full alert inbox. If something has sat three weeks, either do it today or delete it: keeping it there only generates guilt. > [!NOTE] > Tasks arising from a case are best created from it: whoever opens it then sees the context without hunting. **Can I assign a task to someone else?** Yes, and they are notified. **Do they close when the case completes?** No: the task is yours, the case belongs to the process. Close it by hand. **Are they good for recurring work?** For anything that repeats, a process or an expiry alert is better. ## Ejemplos **A manager notes on paper who to phone and loses it.** - Creates the task from the case itself, with a name and a date → Whoever opens it sees the context without hunting, and calls stop being forgotten. **Some things the system cannot do get noted in a personal notebook.** - Records the task in the file itself - Assigns an owner and a date - Checks pending tasks alongside the file's status → What depends on a person stops living outside the file. **A task is agreed in a meeting and nobody notes it.** - Creates it there and then with an owner → The agreement is not lost on leaving the room. **Tasks pile up and nobody knows which are real.** - Reviews and closes those no longer relevant → The list becomes credible again. **One task waits on another and nobody knows.** - Notes what it depends on → The blockage is visible without asking. **Somebody leaves and their tasks stay in their name.** - Reassigns the open tasks → None is orphaned. --- --- id: KB-TD-005 url: https://app.codecontract.io/help/day-to-day/saving-what-you-check-every-week idioma: en categoria: trabajo-diario subcategoria: encontrar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-006, KB-ET-012] citadoPor: [KB-TD-007, KB-IC-008, KB-TD-012] --- # Saving what you check every week _If you navigate to the same thing five times, it should be one click away._ **Responde a:** save a filter · custom case view · quick access to what i always review · i do not want to filter every time Almost everyone repeats the same route every Monday: sign in, filter for what is stuck, sort by age, look. Thirty seconds paid fifty times a year, and exactly what can be saved. ## What is worth saving | View | What for | How often it is checked | | --- | --- | --- | | Stuck more than two weeks | The Monday review | Weekly | | Expiring this quarter | Getting ahead of renewals | Monthly | | Mine, still open | Knowing what is on my plate | Daily | | One site or client | While something is running with them | For the duration | ## The signal If you have reached the same place by filtering three weeks running, that is a view. If you have had to explain to a colleague how to get there, all the more so: what needs explaining is what needs saving. > [!IMPORTANT] > A saved view is not a report. It shows what is there now, not what was: if you need to compare months or show a trend, that is a report and it is generated separately. > [!WARNING] > Saving twenty views is back to the original problem. Three or four per person is what gets used; beyond that you start searching among the views, which is exactly what you were avoiding. > [!NOTE] > If a view serves the whole team and not just you, share it. Half a dozen people repeating the same filter is half a dozen places it can be done differently. **Does it update itself?** Yes, it shows whatever meets the filter at that moment. **Can I share it?** Yes, and it is worth it for team reviews. **Does it replace alerts?** No. You look at a view; an alert comes looking for you. ## Ejemplos **A manager filters for stalled cases every Monday and explains the route to each new joiner.** - Saves the view and shares it with the team → The Monday review stops depending on everyone remembering how to get there. **Every Monday the same four filters are rebuilt by hand.** - Saves the view with its filters - Names it after what it is for - Shares it with whoever looks at the same thing → Monday starts by opening a view rather than building one. **Each person builds their own version of the same query.** - Shares a common view → Everyone looks at the same thing in the meeting. **Fifteen views are saved and nobody knows which to use.** - Archives the ones nobody opens → The list stays useful. **The view stops making sense when the process changes.** - Reviews the views when the circuit changes → The view keeps saying something. **Somebody new does not know what to look at.** - Shares the views the team uses → They find their way on day one. --- --- id: KB-TD-006 url: https://app.codecontract.io/help/day-to-day/sharing-work-across-a-team idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-003, KB-TD-001, KB-TD-017] citadoPor: [KB-TD-008, KB-TD-014, KB-CL-017, KB-TD-018] --- # Sharing work across a team _Giving every case an owner, and what happens when that owner is away._ **Responde a:** assign an owner to a case · who handles each process · a colleague's work while they are on holiday · distributing cases across a team A case with no owner is a stalled case. Not because nobody can touch it, but because everyone assumes someone else has it — and that only surfaces when somebody asks about it three weeks later. ## The rule **One person per case, always.** Not a team, not an inbox: a named person. What belongs to everyone gets done by nobody, and in documentation it shows sooner than anywhere because whoever is waiting is outside. | Situation | Who owns it | | --- | --- | | Onboarding a supplier | Whoever will buy from or contract them | | A site's documentation | That site's manager, not the office | | A signature request to a client | Whoever handles that client | | A mass annual renewal | One person, even if the batch is three hundred | > [!IMPORTANT] > The owner has to be whoever can resolve it, not whoever created it. If the person who built it has neither the supplier's phone number nor any dealings with them, the case will stall at the first chase required. ## When the owner is away 1. **Reassign before leaving** — Planned holiday: hand over whatever can move in those weeks. 2. **If unplanned, look at what is stuck** — The age filter immediately shows what was left ownerless. 3. **If they leave the company, hand everything over** — That same day, not at month end. > [!WARNING] > Reassigning restarts nothing: the case keeps its history and the third party does not learn that whoever handles it has changed. The only thing that changes is who receives the notices. > [!NOTE] > If nobody wants to own a case, it usually should not exist. That is a good signal to close it with its reason. **Can there be two owners?** Technically yes; in practice it is the same as none. **Does the third party see who owns it?** They see who they are dealing with, which is what matters to them. **Can I filter by owner?** Yes, and it is the most useful Monday view. ## Ejemplos **A manager takes three weeks off and returns to nine cases that never moved.** - Hands over the ones that could progress before leaving - Leaves the rest marked as hers → Returns to two stalled instead of nine, and none for lack of someone to handle them. **Three people handle supplier onboarding and two write to the same one on the same day.** - Assigns each file to an owner - Works on the shared file rather than on copies - Checks who has what before allocating more → The supplier receives one request, not two, and the split is visible without asking. **Work is allocated verbally in Monday's meeting.** - Records the assignment → Nobody doubts what is theirs. **One person carries twice the load of the rest.** - Checks the load per owner → The split is adjusted with data. **Somebody goes on holiday with open files.** - Reassigns before they leave → No file is left waiting. **Nobody knows which files have no owner.** - Checks the unassigned ones → Orphaned work becomes visible. --- --- id: KB-TD-007 url: https://app.codecontract.io/help/day-to-day/someone-needs-a-document-right-now idioma: en categoria: trabajo-diario subcategoria: encontrar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-006, KB-TD-005, KB-TD-019] citadoPor: [KB-TD-010] --- # Someone needs a document right now _Finding it and sending it properly, with a client or an inspector waiting._ **Responde a:** i need a document urgently · an inspector is asking for a paper now · send a document to a client quickly · find a contract fast Someone is waiting: an inspector at the door, a client on the phone, a lawyer with a deadline. It is thirty seconds of searching and a thirty-second decision about how to send it. Both go wrong in a hurry. ## Finding it 1. **Search by what it says, not where you think it is** — A tax ID, a registration, a policy number. Almost nobody remembers the filename. 2. **If too much comes back, filter by date** — Faster than adding words, which usually yields nothing. 3. **If nothing comes back, check the organisation and your permissions** — The two commonest causes, and neither is a search problem. ## Sending it | Who is asking | How to send it | | --- | --- | | An inspector, on site | Show it on screen; nothing needs sending | | A client who only needs to see it | A link: no loose copy and it is logged | | A lawyer or a court | The original file with its receipt, not a printout | | Someone outside asking by email | Verify who they are before sending anything | > [!IMPORTANT] > The last row is the one skipped in a hurry and the costliest. An urgent email asking for a document with sensitive data is exactly the shape of a fraud: if you were not expecting that request, phone the number you already had before sending anything. > [!WARNING] > Do not send a screenshot or a scanned printout when the document has to prove something. Reprinting a PDF changes it, and verification will then say it does not match — correctly. > [!NOTE] > If the same document is asked for three times a month, link it from where you work. Urgency is solved before it arrives, not when it does. **Can I grant access instead of sending the file?** Yes, and it is usually better: checked on the spot, no copy left. **Is there a record that I sent it?** Yes, with date and recipient. **What if I lack permission to see it?** Ask an administrator; a hurry is the worst moment to decide to bypass that. ## Ejemplos **An urgent email asks for a client's contract and the associated bank details.** - Phones the number they already had for that client - Confirms nobody requested anything → Avoids sending bank details to someone impersonating their client, which was the point of the urgency. **A client asks for a certificate by phone and it has to be hunted across three folders.** - Searches by content rather than by file name - Shares from the platform instead of downloading and attaching → It is delivered while the client is still on the phone, and there is a record of what was sent. **The document exists under a name nobody remembers.** - Searches by something inside the document → The file name stops deciding whether it is found. **It is emailed and there is no record it was sent.** - Shares from the file → There is a trail of who received it. **The whole file is sent when one document was asked for.** - Shares only what is relevant → No extra information is handed over. **The document sits in the inbox of somebody who is away today.** - Uploads it to the file on receipt → Delivery does not depend on who is in that day. --- --- id: KB-TD-008 url: https://app.codecontract.io/help/day-to-day/coming-back-from-holiday idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-TD-006] citadoPor: [KB-TD-020] --- # Coming back from holiday _Three weeks away and two hundred things waiting: where to start._ **Responde a:** catching up after holiday · what do i check first on my return · backlog after an absence · handing over before holiday The first day back can be lost entirely to looking at things. What stops that is not trying to catch up on everything: almost nothing from three weeks ago needs your attention now. ## The order on return 1. **What stalled waiting for you** — Filter for yours stuck since you left. It is usually little and the only urgent part. 2. **What expired while you were away** — That is what may have caused a problem with nobody watching. 3. **What arrived and awaits review** — Approve or reject in bulk, without opening them one by one. 4. **And that is it** — The rest resolved itself or someone handled it. Reviewing it is curiosity, not work. > [!IMPORTANT] > What causes most trouble from an absence is not what piled up: it is what expired with nobody looking. Insurance that lapsed two weeks ago has been a problem for two weeks, and appears in no inbox. ## Twenty minutes before leaving **En corto** - Reassign whatever can move in those weeks. - Check what expires while you are away and resolve it first. - And say who decides what you would decide. > [!WARNING] > Reassigning is not dumping work on a colleague: it is so the third party waiting does not discover their contact is on holiday three weeks after asking. > [!NOTE] > If forty things are waiting specifically for you on your return, the problem is not the holiday: it is that everything passes through one person, and that shows in January too. **Can I set an auto-reply?** For email yes; third parties waiting on documents appreciate knowing who to write to. **What if nobody can cover for me?** Then at least reassign what expires: that is what cannot wait. **Does the third party know the owner changed?** They see who they deal with; the history is not reset. ## Ejemplos **Someone returns from three weeks away and spends the first day reviewing everything that happened.** - Filters only their own stalled and expired items - Approves the review queue in bulk → Closes the urgent part in an hour and finds two expiries nobody had seen for weeks. **You come back from three weeks off to four hundred emails and eleven files that moved.** - Checks first what is waiting on your side - Looks separately at what has been stalled since before you left - Leaves the inbox until after you know where you stand → The return starts from a short list rather than from an inbox. **Nobody knows what happened to the files while you were away.** - Checks each one's history → You pick up knowing what moved. **The stand-in did things and there is no record of what they decided.** - Checks the recorded decisions → Continuity does not depend on a conversation. **You return and some expiries have passed.** - Checks what expired during the absence → The urgent is tackled first. **Suppliers were not told before you left.** - Redirects notices to the stand-in before leaving → Nobody outside waits three weeks. --- --- id: KB-TD-009 url: https://app.codecontract.io/help/day-to-day/when-a-third-party-replies-on-another-channel idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-002, KB-CC-002, KB-TD-004] citadoPor: [KB-TD-020] --- # When they reply on WhatsApp instead of using the link _It happens constantly, and dropping the document into a chat has a cost._ **Responde a:** the supplier sends documents by whatsapp · they reply to my email instead of using the link · documents arriving through another channel · uploading what they send me by chat You send a link and they reply with a photo on WhatsApp. Or answer your email with the PDF attached. It happens constantly and it is not ill will: they did whatever was easiest for them. ## What is lost if it stays there | What is lost | And that means | | --- | --- | | The real delivery date | There is no record of when it arrived, only when you uploaded it | | Who delivered it | The record shows you uploaded it, not them | | The case stays incomplete | Nobody else sees it is resolved | | The document lives on a phone | And on the sender's, uncontrolled | > [!IMPORTANT] > The first one is what genuinely matters. If you later have to prove that supplier delivered on time, a document you uploaded two weeks later does not prove it — it proves you uploaded it two weeks later. ## What to do, by case 1. **If it is one-off, upload it and note where it came from** — Worse than the normal circuit, but better than leaving it in the chat. 2. **If it always happens with that person, change their channel** — If WhatsApp is their natural habit, send the request on WhatsApp: the link works the same. 3. **If it happens with many, look at your request** — When most reply elsewhere, the problem is not them: the link is not understood or not visible. > [!WARNING] > Be careful with what arrives by chat unchecked. A document arriving on WhatsApp from a number you do not have saved deserves the same suspicion as an unexpected email, more so if it comes with urgency. > [!NOTE] > The link working from WhatsApp is exactly what solves this: you do not have to choose between their convenient channel and the circuit that leaves a record. **Can I forward the document into the case myself?** Yes, and note that it arrived on another channel and when. **Can I request via WhatsApp with a link?** Yes, it is the same link on another channel. **What if they insist on emailing it?** Upload it, but check whether your request is understood: it usually is that. ## Ejemplos **A supplier always sends certificates on WhatsApp and someone uploads them manually days later.** - Their request channel is switched to WhatsApp → They deliver through the link from their phone, and the delivery date is theirs again rather than the uploader's. **A supplier sends a photo of the certificate on a messaging app and the file stays empty.** - Uploads the photo to the file on receipt - Replies with the link for next time → The delivery is recorded and the supplier learns the route without argument. **The photo stays on the phone of whoever received it.** - Uploads it at the moment, from that phone → The record does not depend on a handset. **It arrives by messaging and nobody knows if it is the requested document.** - Checks before treating it as delivered → The file reflects what is really there. **The supplier always sends that way because it is what they use.** - Sends them the link on that same channel → They use the channel they know, with the record you need. **It is accepted by messaging and nothing is recorded.** - Records which route it arrived by → The history reflects what happened. --- --- id: KB-TD-010 url: https://app.codecontract.io/help/day-to-day/finding-something-from-years-ago idioma: en categoria: trabajo-diario subcategoria: encontrar audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-006, KB-TD-007, KB-TD-012] citadoPor: [KB-TD-019] --- # Finding something from years ago _When you remember neither the name, nor the date, nor who uploaded it._ **Responde a:** find an old document · i do not remember the filename · find something from three years ago · searching without knowing the date Something from three years ago is searched for differently from last week's. You do not remember the name, the date is approximate, and whoever uploaded it may have left. What you almost always remember is something it said inside. ## Where to start, in order 1. **An identifier that does not change** — A tax ID, a registration, a policy or case number. It finds fastest. 2. **The other party's name** — The company or person it was with. Better remembered than anything else. 3. **The matter it belonged to** — The site, the client, the project. And from there, inside. 4. **And only last, the date** — As a narrowing filter, not a starting point. > [!IMPORTANT] > Searching by date first is the commonest mistake and the biggest time sink. The date you remember is usually off by months, and filtering on it discards exactly what you are looking for without you noticing. ## If it does not appear | Possible cause | How to rule it out | | --- | --- | | You are in another organisation | Check at the top: the silliest and commonest cause | | You lack permission to see it | Ask an administrator | | It was a scan uploaded without reading | Search the filename or the matter | | It was never here | It may be in someone's email from back then | > [!WARNING] > The third row misleads most. A scanned document uploaded without reading is not searchable by content: it exists, but it does not answer what you are looking for inside it. ## So it does not happen again **En corto** - That what is uploaded gets read, unless there is a reason not to. - That each document lives in the matter it belongs to, not loose. - And that what is consulted often is linked from where you work. > [!NOTE] > If you find it after twenty minutes, spend two more making it findable: it is the only way the next time does not cost another twenty. **Can I search by an extracted value?** Yes, and it is the most precise: amounts, expiry dates, identifiers. **What if the uploader has left?** Their history remains; what left is the person, not what they did. **Can I search old scanned documents?** If they were read on upload, yes. If not, they can be reprocessed. ## Ejemplos **Someone searches for a four-year-old contract by date and cannot find it.** - Searches the other party's tax ID → It appears in seconds, with a real date five months off from what they remembered. **A client asks about a shipment from four years ago and the archive sits in three places.** - Searches by something in the content rather than by date - Checks the complete file with its history → You answer with what existed then rather than with what is remembered. **Old scans do not appear in searches.** - Checks whether they were processed on upload → The history becomes searchable. **The search uses the supplier's name from back then, which has changed.** - Searches by the document's content → The name change stops hiding the archive. **The document was migrated and lost its context.** - Checks which file it ended up attached to → You reach it from where the question starts. **Nobody knows whether the document was kept that long.** - Checks the retention policy applied → You know what to expect to find. --- --- id: KB-TD-011 url: https://app.codecontract.io/help/day-to-day/living-with-the-old-system idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-PS-006] citadoPor: [KB-TD-017] --- # Living with the old system _For a few months you will have two places. How to manage without duplicating work or losing things._ **Responde a:** running two systems at once · migrating gradually without stopping work · what to do with the old shared folder · transitioning between document systems Nobody switches systems overnight. For a few months some things will be here and some in the usual folder, and that period is where documents go missing and where people decide whether the change is real. ## The rule that makes it work > [!IMPORTANT] > **New material comes in here from day one; old material comes in only when it is needed.** Without that rule you end up maintaining both places in full, which is double the work and why most transitions get abandoned. ## What goes where during the overlap | Situation | Where it goes | Why | | --- | --- | --- | | A new document arriving today | Here, always | If there are exceptions, there is no rule | | An old document someone consults | Uploaded as it is consulted | You bring what gets used, which is little | | An old document nobody touches | Stays where it is | Bringing it adds nothing | | An old document expiring soon | Bring it now | It is the one you will need | ## How to run the period 1. **Set a cut-off date and say it out loud** — "From Monday the 3rd, whatever arrives goes here." Without a date there is no cut-off. 2. **Make the old system read-only when you can** — While both can be written to, both will be written to. 3. **Bring the expiring items first** — Insurance, certificates and contracts with end dates. They are what you will need soonest. 4. **And review after two months what has come across** — Usually 10% of the archive. That figure tells you how much of the rest was unnecessary. > [!WARNING] > The costliest failure is not technical: it is someone still saving to the old folder "just this once". Within a month there are two truths and nobody knows which to check. If you spot that, it is more urgent than any migration. ## When you can call it done **En corto** - When nobody has opened the old system in a month. - When everything with an expiry date is here. - And when the answer to "where is this?" is no longer "it depends". > [!NOTE] > The old archive need not be deleted. It can stay read-only for as long as you like: what matters is that it stops receiving new material, not that it disappears. **Can I upload everything at once?** You can, and sometimes it pays. But bringing what nobody looks at only buries what matters. **How long does the overlap last?** Weeks with a cut-off date; indefinitely without one. **What if the team resists?** It is almost always because they cannot find something. Look at that before insisting. ## Ejemplos **A team has spent four months with documents in two places and no longer knows which is right.** - Sets a cut-off date and makes the old folder read-only - Uploads what expires this year first → Within three weeks "where is this?" stops having two answers. **For six months the old and new systems coexist and nobody knows which to check.** - Sets the date from which only the new one counts - Leaves the old one read-only - Announces the cut-off to the whole team → There stop being two truths and nobody works in the wrong place. **A document is uploaded to the old system out of habit.** - Closes document intake on the old one → New material lands where it should. **You search the new one and the document is in the old.** - Notes which period each one covers → You know where to look without trying both. **The old system is switched off with documents nobody migrated.** - Checks what remains before switching off → Nothing is lost along the way. **Nobody decides when the old one gets switched off.** - Sets a date and an owner → The overlap ends rather than lasting forever. --- --- id: KB-TD-012 url: https://app.codecontract.io/help/day-to-day/the-half-hour-tidy-up-each-month idioma: en categoria: trabajo-diario subcategoria: encontrar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-005, KB-ET-012] citadoPor: [KB-TD-010] --- # The half-hour tidy-up each month _What degrades by itself if nobody looks, and how to fix it without a project._ **Responde a:** keeping documentation tidy · cleaning up duplicate contacts · periodic review of the document system · why finding things keeps getting harder A document system does not break suddenly: it degrades. Every month brings duplicate contacts, files nobody closed, templates no longer used, and alerts going to people who left. Two years in, searching costs twice as much and nobody knows why. ## The five things worth checking 1. **Files stuck for more than three months** — Either restart or close them. Leaving them open pollutes every count. 2. **Duplicate or dormant contacts** — The same supplier with three records is the number one cause of "I can't find it". 3. **Alerts going to people who have left** — Alerts nobody reads are worse than no alerts. 4. **Templates that no longer match how you work** — An outdated template keeps being used, which is why it hurts. 5. **And outsiders' access** — The accountancy firm from two years ago, the consultant on the finished project. > [!IMPORTANT] > The half hour pays for itself the same month. The commonest cause of "this is slow" or "I can't find anything" is not volume: it is duplicates and things left open that are not. ## What NOT to do in that half hour | Temptation | Why not | | --- | --- | | Reorganise the whole structure | Half an hour will not do it and you will leave it halfway | | Delete old documents | They take little space and deleting is irreversible | | Change how the team works | That is not tidying, it is a project with its own conversation | > [!WARNING] > And above all, do not leave it for "when there's a gap". The gap never comes, and degradation compounds: half an hour a month is trivial; eight hours a year, once it hurts, is hard to get anyone to commit to. ## How to know it is needed **En corto** - Someone says "ask X, he knows where it is". - Two records for the same supplier show up in a search. - Alerts get ignored because "they're nearly always about old stuff". - And reports come out with numbers nobody believes. Any of the four means the tidy-up has been skipped for a while. All four together mean it will happen anyway, just in the form of an incident. > [!NOTE] > Have the same person do it at the same point each month. Not for bureaucracy: because that is how you spot drift by comparing with last month, which is the part that actually warns you. **What if we are very few?** All the more reason: degradation does not depend on size and here nobody fixes it behind you. **Can it be automated?** Alerts about what is stuck, yes. Deciding what to close, no. **Is half an hour realistic?** Not the first month; from the second, yes. ## Ejemplos **A team complains that finding things keeps getting harder.** - Spends half an hour on duplicates, stuck files and external access → Searches return one result instead of three, with nothing about how they work changed. **Over a year, forty half-closed files and twelve unused templates pile up.** - Reserves half an hour a month to review - Closes what is only awaiting confirmation - Archives templates with no activity → The open list becomes credible again and the metrics say something. **There are duplicate contacts at the same company.** - Merges duplicates in the monthly review → The supplier receives one, not three. **Documents past their retention period pile up.** - Reviews what is due under the policy → The archive stops growing without criteria. **There are active accounts for people who have left.** - Cross-checks users against joiners and leavers → The active accounts are the right ones. **The clean-up is postponed because it is never urgent.** - Puts it in the calendar like any other task → It happens because it is due rather than when it hurts. --- --- id: KB-TD-013 url: https://app.codecontract.io/help/day-to-day/the-day-something-is-down idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-009, KB-PR-001, KB-TD-018] citadoPor: [KB-TD-001] --- # The day something is down _What you can carry on doing, what to postpone, and what NOT to do._ **Responde a:** the platform is slow what do i do · cannot work today system down · carrying on when the system fails · plan b when something is not working One day something will not work: the system, your connection, a third party's email. The difference between a lost morning and a nuisance is having decided beforehand what to do and, above all, what not to do. ## The first three minutes 1. **Check whether it is yours or general** — Have someone else try from another connection. It saves half the calls. 2. **Check the status page** — If it is general, they already know and there is little to add. 3. **And tell whoever was expecting something today** — A two-line notice prevents five calls and a bad impression. > [!IMPORTANT] > The third point is what the other side values most. A deadline that slips with notice is manageable; the same deadline unannounced becomes a trust problem lasting far longer than the incident. ## What you can carry on doing | Yes | Better not | | --- | --- | | Taking photos and preparing them to upload later | Going back to paper "just for today" | | Calling whoever has something outstanding | Sending the same thing several times | | Drafting and leaving things ready | Redoing work that may already be saved | | And noting what happens, with times | Writing off what was in progress | > [!WARNING] > The second row on the right consumes most and causes the most mess afterwards: retrying a send that did go through leaves the recipient with three identical emails and you with three charged actions. Check the status before repeating anything. ## Getting back to normal **En corto** - Upload whatever was done outside the system, the same day. - Check whether anything was left half-done before assuming it completed. - And note what happened in the affected file, if it had consequences. That last point is not bureaucracy: if a deadline was missed because of an outage, being able to say when it started and when it was resolved changes the conversation entirely. > [!NOTE] > The fourth row on the left — noting with times — is what lets you explain it afterwards. Reconstructing three days later exactly when something stopped working is impossible and sounds like an excuse. **Is what I was writing lost?** What was saved is there; what never saved is not. When unsure, check before redoing. **Who do I tell if it is general?** Whoever was expecting something from you. The technical incident is already being handled. **What if it is just slow?** Work on what does not depend on uploading large files and leave those for later. ## Ejemplos **A team loses a morning retrying sends during an incident.** - Checks whether it is general and warns clients expecting delivery that day - Prepares photos and drafts to upload later → The afternoon is fully recovered and no recipient gets duplicate sends. **Something is not working and the team sits idle for half a morning.** - Checks whether it affects others or just one person - Carries on the alternative way while it is fixed - Reports with the time, the screen and the error code → Work does not stop and support starts with a diagnosis rather than a question. **«It does not work» is reported with no detail.** - Describes what was expected and what happened → The first reply is already useful. **Five people report the same thing separately.** - Checks whether a case is already open → The problem is worked once. **People wait for a fix without telling the suppliers.** - Warns whoever is waiting on something → Nobody outside is left without an explanation. **It is resolved and no record remains of what happened.** - Records the incident and its resolution → Next time it is resolved in minutes. --- --- id: KB-TD-014 url: https://app.codecontract.io/help/day-to-day/delegating-without-losing-control idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-006, KB-CR-011] citadoPor: [KB-CL-017] --- # Delegating without losing control _Sharing out the work and still knowing how it is going, without asking every day._ **Responde a:** delegating without losing visibility · how to know if delegated work is progressing · sharing files across a team · following up without micromanaging Delegation nearly always fails the same way: whoever delegates loses visibility and recovers it by asking, and whoever received the work reads those questions as distrust. It is not a people problem: the state of the work is not anywhere both can look. ## What to make clear when delegating 1. **What "finished" means** — Not "handle this supplier's onboarding", but what must be done to call it closed. 2. **Which decisions they can take and which not** — It prevents both paralysis and unpleasant surprises. 3. **By when** — With a date. "Whenever you can" competes with everything else and loses. 4. **And where progress will be visible** — The point almost nobody agrees, and the one that makes daily questions unnecessary. > [!IMPORTANT] > The fourth point replaces supervision. If the state is visible in the file, the delegator looks whenever they want without interrupting, and the doer does not have to report. Both gain the same thing: they stop talking about status and start talking about problems. ## What to look at, and how often | What | How often | Why | | --- | --- | --- | | Whatever has been stuck longest | Weekly | That is where the problem is, not in what is moving | | Whatever is due soon | Weekly | It is the only genuinely urgent thing | | Everything else | Not needed | Looking at it is micromanagement by another name | > [!WARNING] > If you find yourself reviewing every delegated file, you have not delegated: you have shared out execution and kept the duty to watch, which is the part that eats time. ## When something gets stuck **En corto** - Ask about the obstacle, not the progress. - And if the obstacle is another person, that is where you step in. - What does not work is reassigning without asking first. Reassigning a stuck file without talking usually solves that case and spoils the next: the person it was taken from will stop flagging when something gets difficult. > [!NOTE] > If a file has no named owner it is not delegated: it is in the air. "The team" answers for nothing, and that is always discovered late. **What if I delegate to someone new?** More detail on what "finished" means, same review frequency. **Should several people share a file?** One answers and others help; two owners is none. **How do I know if I am micromanaging?** If you are asking about things you could look at yourself, you are. ## Ejemplos **A manager delegates fifteen files and ends up asking about them every morning.** - Agrees what "finished" means and where progress is visible - Reviews only what is stuck and what is due → Stops asking, and the team starts flagging obstacles on its own. **Supplier onboarding is delegated and every file is still reviewed one by one.** - Assigns files to whoever handles them - Checks the overall status instead of case by case - Keeps review for what falls outside the pattern → Control is kept without repeating the work of whoever does it. **It is delegated and nobody knows what criteria to apply.** - Writes the criteria into the template → Decisions are the same whoever takes them. **It is delegated and what gets stuck drops out of sight.** - Reviews what is stalled once a week → The blockage is visible without looking at everything. **Whoever receives the delegation cannot close files.** - Adjusts permissions to the delegated work → The delegation genuinely works. **It is delegated and then corrected behind their back.** - Discusses the correction with whoever handles it → The criteria get learned rather than the error repeated. --- --- id: KB-TD-015 url: https://app.codecontract.io/help/day-to-day/planning-the-week-in-fifteen-minutes idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-CR-013] citadoPor: [KB-TD-016] --- # Planning the week in fifteen minutes _Four checks on Monday that prevent Thursday's emergencies._ **Responde a:** organising the documentation week · what to review every monday · avoiding last-minute emergencies · weekly follow-up routine Day-to-day work runs off the inbox, and that is enough to react. What prevents emergencies is something else: a fixed slot each week looking at what is **not yet** urgent. It is four checks and they fit in fifteen minutes. ## The four 1. **What expires in the coming weeks** — Not this week's, which you already know: three or four weeks out. It is the only thing that gives margin. 2. **What has been stuck longest** — The oldest file with no movement. Not the most urgent: the oldest. 3. **Who has not replied to the second reminder** — At that point it stops being chasing and becomes a decision you have to take. 4. **And what you promised last week** — The check that saves the most credibility and that nobody does. > [!IMPORTANT] > The second is counterintuitive and pays off most. Urgent things already have someone pushing them; what has sat for six weeks has nobody, and that is exactly where next month's crises come from. Look at the old, not the loud. ## What does NOT fit in those fifteen minutes | Not this | Why | | --- | --- | | Reviewing file by file | If that is needed, the problem is delegation, not routine | | Rebuilding templates or processes | That is another day's work, with time | | Answering everything that comes up | Note it and move on: answering turns it into a morning | > [!WARNING] > The mistake that makes this get abandoned within two weeks is replying while reviewing. The review is to **decide what needs doing**, not to do it. Note and close; if something cannot wait two hours, it was already urgent and was in the inbox. ## When to do it **En corto** - The same day at the same time, ideally Monday morning. - Before opening email, not after. - And with the list in front of you, not from memory. Monday-before-email is not a quirk: the moment the inbox opens, other people's urgencies set your week. Fifteen minutes earlier is the only window where you decide. > [!NOTE] > If you are two or three, do it together: half the blockages get resolved on the spot, because what one person has stuck usually depends on something another can unblock in a minute. **What if there is no time that week?** Do only the first and the fourth: they prevent the most grief. **Should anything be written down?** What you decide, yes. What you looked at, no. **Does it work for a large team?** Yes, but each with their own patch; a twenty-person review is not a review, it is a meeting. ## Ejemplos **A manager spends the week firefighting and cannot see where the fires come from.** - Blocks fifteen minutes on Monday for what expires in three weeks and the oldest stuck file → Within a month emergencies drop, because they are being seen while they still are not emergencies. **Monday goes on reconstructing what is outstanding and what expires.** - Opens the saved view of what is waiting for action - Checks what expires in the next fortnight - Allocates whatever needs allocating before starting → The week starts with a plan in fifteen minutes rather than a morning of review. **Planning happens without knowing what depends on third parties.** - Separates what waits inside from what waits outside → What depends on somebody else is launched first. **On Monday you plan what expired the previous Friday.** - Also checks what has already expired → What is overdue does not fall behind another week. **Each person plans their part and nobody sees the whole.** - Shares the team view → The split is decided with the full picture. **The plan is made and not revisited until the following Monday.** - Checks mid-week what has drifted → The correction arrives in time. --- --- id: KB-TD-016 url: https://app.codecontract.io/help/day-to-day/when-almost-everything-waits-on-someone-else idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-015, KB-CF-005] citadoPor: [KB-TD-017] --- # When almost everything waits on someone else _Half your list does not move because it is not up to you. How to handle that without living in pursuit._ **Responde a:** my work depends on others replying · managing tasks blocked by third parties · cannot progress until they send it · organising work with many waits Documentation work has a feature that makes it exhausting: most of what you have open does not depend on you. It is waiting on a supplier, an adviser, a client. And a list full of things you cannot push creates the feeling of falling behind even when you are doing everything possible. ## Separate what can be separated | State | What it means | What to do with it | | --- | --- | --- | | Mine to act on | I can move it now | This is your real list, and it is usually short | | Waiting on someone outside | Already requested, with reminders running | Do not look daily: look when it is due | | Waiting on someone inside | It depends on a colleague | The only thing to unblock by talking | | Stuck for no reason | Nobody is pushing and nobody is waiting | Decide: restart or close | > [!IMPORTANT] > The fourth row pollutes everything else and gets the least attention. While files sit stuck with nobody knowing why, any count of "pending" mixes real work with noise — and the feeling of being swamped comes as much from the noise as from the work. ## What changes when you work this way 1. **Put chasing on automatic and out of your head** — If the reminder goes by itself, waiting stops being your task. 2. **Fix when you look at what is waiting** — Once a week. Looking daily does not speed it up and wears you down. 3. **And put an end to every wait** — "If it is not here by Friday, I do X". Without that end, the wait is infinite by definition. > [!WARNING] > The real strain does not come from having things waiting: it comes from not knowing which are waiting on someone and which have simply gone quiet through neglect. Once those two are distinguishable at a glance, the same amount of pending work weighs half as much — and that is not an impression, it is that you stop mentally re-checking what is already handled. ## How to talk about it with whoever asks **En corto** - "Requested on the 3rd, with two reminders" is a professional answer. - "I'm waiting" on its own does not sound like one, even though it is the same. - And if you get asked often, give them access to the status instead of answering. The third solves the whole case when the asker is a manager or a client: once they can look, they stop asking, and you stop interrupting what does depend on you. > [!NOTE] > If separating the list shows that what is yours to do is very little and you are still short of time, the problem is not the workload: it is the constant interruption to report on the rest. **What if the one not replying is a client?** Same criterion, different tone: the end of the wait exists all the same, it is just communicated differently. **How many reminders before escalating?** Two, spaced. By the third it stops being chasing and becomes a decision. **Should things stuck for months be closed?** Yes, noting why. A file closed with a reason informs; one left open without a reason does not. ## Ejemplos **A manager has sixty open files and the constant feeling of never advancing.** - Separates what is theirs from what is waiting and closes what is stuck for no reason - Leaves chasing on automatic and reviews waits weekly → Their real list turns out to be eight items, and they clear it in two days. **Of twenty open files, sixteen wait on somebody outside and the team feels stuck.** - Separates what waits outside from what waits inside - Works the short list that does depend on you - Lets the reminders work the long one → The sense of being blocked lifts because your own list is short and moving. **What is waiting on third parties is reviewed daily.** - Reviews it once a week → Time goes on what does depend on you. **Daily chasing means the supplier stops reading.** - Spaces out the reminder cadence → The nudge works again. **A file has waited two months and nobody decides.** - Sets an escalation or closing criterion → The file does not stay open forever. **Management asks why nothing is moving.** - Shows what waits inside and what waits outside → The conversation happens with data. --- --- id: KB-TD-017 url: https://app.codecontract.io/help/day-to-day/closing-a-file-properly idioma: en categoria: trabajo-diario subcategoria: tareas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-016, KB-TL-012, KB-TD-011] citadoPor: [KB-TD-006] --- # Closing a file properly _Finishing the work and closing the file are two different things, and hardly anyone does the second._ **Responde a:** when to close a file · what to check before closing · finished files still open · close or leave open Almost every file ends without being closed. The work finishes, people move on, and the file stays open forever — until someone counts what is outstanding and gets a figure that means nothing. ## What not closing costs | Consequence | How it shows | | --- | --- | | Counts stop being useful | "We have eighty open" and forty are done | | Reminders keep going out | To third parties who already delivered, and you look bad | | The same things get reviewed weekly | Someone looks, sees it is fine, and does not close it either | | And what is genuinely stuck hides | Among those that only look stuck | > [!IMPORTANT] > The fourth does the real damage and is hardest to see. If forty of eighty open files are finished, the five blocked for months do not stand out — they are lost in the noise. **Closing is not tidiness: it is what makes the real problem visible.** ## What to check before closing 1. **That no requests remain open** — That is what keeps sending reminders after the work is done. 2. **That what must be kept is there** — Whatever you will be asked for about this matter in future. 3. **That what was promised is done or noted** — An outstanding commitment in a closed file disappears. 4. **And that any exceptions are closed** — An open exception in a closed file is the worst combination. > [!WARNING] > The case worth handling separately: the file that will **not** be completed. It is not closed like a finished one — it is closed saying why. "Closed incomplete: the supplier never supplied insurance and we decided not to work with them" informs; closing it silently leaves whoever looks in two years thinking you forgot. ## When it should stay open **En corto** - While there is genuinely something you expect from someone. - If there is a live deadline that could still move. - And if it is part of something larger still running. Outside those three, an open file is not caution: it is noise that will stop someone seeing what matters. > [!NOTE] > Closing deletes nothing: the file stays complete, searchable and with its history. All that changes is that it stops counting among what is in progress and stops generating alerts. **Can it be reopened?** Yes, and that is normal if something new comes up on that matter. **What if a minor document is missing?** Decide: either request it and keep it open, or close it noting it was not requested. **Who should close it?** Whoever owned it. If nobody owned it, that was the underlying problem. ## Ejemplos **A team counts eighty open files and cannot tell which matter.** - Closes the finished ones and notes the reason on those never completed → Twelve genuinely open remain, and the five stuck for months are visible at once. **A file is treated as closed and two months later a document is missing.** - Checks what is outstanding before closing - Records the reason for closing - Notes whether anything is deliberately left open → Closing means the same to the whole team and can be explained months later. **It is closed and reminders keep going out.** - Stops the open processes on closing → Nobody outside receives requests about something closed. **Nobody knows why a file was closed incomplete.** - Notes the reason in the closure itself → The decision is explicable. **The file is reopened and the earlier work is lost.** - Reopens instead of creating a new one → The history is preserved. **Metrics count dead files as open.** - Closes what will not progress → The numbers say something again. --- --- id: KB-TD-018 url: https://app.codecontract.io/help/day-to-day/the-work-nobody-owns idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-006, KB-TD-001] citadoPor: [KB-TD-013] --- # The work nobody owns _What has no owner appears in nobody's inbox, which is why it surfaces late and always from outside._ **Responde a:** files nobody is handling · we missed a deadline · work with no assigned owner · how to review what has no owner A well-set-up inbox shows what is yours: what you owe, what you are waiting for and what is running out of time. It works so well that it creates a perfect blind spot — what belongs to nobody appears in no inbox, and therefore does not exist until someone outside calls. ## Where orphan work comes from | Origin | Why it ends up ownerless | | --- | --- | | Someone left or changed role | Their work stopped showing for them and showed for nobody else | | It was created automatically | A rule opened it and there was nobody to assign it to | | It came in through an unusual channel | It arrived as a loose reply and nobody claimed it | | It belongs to everyone | «Someone is on it» is the fastest way for nobody to be | > [!IMPORTANT] > The fourth row does the most damage and is the least obvious: **a shared owner works exactly like no owner**. When something belongs to a whole team, each person reasonably assumes another is watching it, and the alert that fires four times is ignored four times. What gets shared is the workload; the owner is always one person, even when three do the work. ## The five-minute review 1. **Once a week, look at what has no owner** — A short list if checked regularly, a very long one if not. 2. **Assign each item to someone, even provisionally** — A provisional owner spots the problem; none does not. 3. **And look at whatever has been still longest** — What has not moved in weeks is usually what belongs to nobody. > [!WARNING] > The moment this fires is always the same: **when someone leaves**. Removing their permissions is quick and everybody remembers; sharing out what they were carrying requires knowing what they carried, and that is only knowable while they are still there. Half an hour with that person before they go is worth weeks of archaeology afterwards. ## How to stop it being created **En corto** - Every file is born with an owner, even if it changes later. - So is anything an automatic rule creates: with nobody obvious, it goes to a default person. - And when someone goes on holiday or leaves, their work is reassigned rather than orphaned. > [!NOTE] > Having an owner does not mean it gets done on its own: it means there is someone to ask about it. That is the difference between an oversight and a problem nobody discovers. **What if we genuinely do not know whose it is?** Assign it to whoever will find out. That already counts as an owner. **Does assigning everything create work?** Less than a missed deadline you then have to explain. **How often should we review it?** Weekly while there is a backlog; after that, the monthly tidy-up is enough. ## Ejemplos **A company finds a missed deadline on a file handled by someone who has left.** - Reviews ownerless work weekly and reassigns whenever someone departs → The blind spot disappears, because everything shows up in one specific person's inbox. **Some tasks belong to no department and have gone months undone.** - Assigns an owner, even provisionally - Gives them a review date - Checks monthly what is still ownerless → Orphaned work stops piling up quietly. **Everyone assumes somebody else is doing it.** - Records the assignment → Nobody doubts whose it is. **It is assigned to a department and nobody specific picks it up.** - Assigns to a person, not an area → There is somebody to ask. **The ownerless task blocks a file.** - Checks which files depend on it → Priority is decided knowing the impact. **The matter is closed without anyone doing it.** - Records that it was decided not to, and why → The omission is a documented decision. --- --- id: KB-TD-019 url: https://app.codecontract.io/help/day-to-day/when-what-you-need-is-not-a-document idioma: en categoria: trabajo-diario subcategoria: encontrar audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-010, KB-DI-009] citadoPor: [KB-TD-007] --- # When what you need is not a document _«When does it expire?», «what is the cover?». The answer is not a file: it is one line inside one._ **Responde a:** searching for a value inside a document · when does this supplier's insurance expire · getting a figure without opening the pdf · searching by amount or date Half a dozen times a day the question is not «where is the contract» but «how long is it valid» or «what does it cover». Those are different questions, and searching for them the same way is what turns five seconds of work into five minutes. ## Two searches that get confused | What you need | What to search for | How it ends | | --- | --- | --- | | The document, to send it | By its name or who issued it | You download and send it | | A value from the document | By the value, not the file | You answer without opening anything | | Everything meeting a condition | By the value, across all at once | You get a list, not a document | | Whether something changed | By the value, comparing versions | You see what changed and when | > [!IMPORTANT] > The mix-up is costly for a not-obvious reason: **a file's name says nothing about what is inside**. `scan_2024.pdf` may be the policy expiring next month, and no naming scheme, however good, will tell you the sum insured. When the question is about a value, searching by name only leads you to a document you then have to open and read — and with thirty suppliers, to thirty documents. ## What has to be decided once 1. **Which values you are actually asked for each week** — Expiry, amount, number, holder: usually four or five. 2. **That those get extracted on upload** — A value that is not extracted cannot be searched or watched. 3. **And check them the first time** — A misread value spreads to every answer that depends on it. > [!WARNING] > The consequence of holding values outside the document is the one people do not anticipate: **what is extracted can be monitored; what lives only inside the PDF cannot**. An expiry date existing only as text on a scanned page can warn you of nothing, however neatly it is filed. Deciding what gets extracted is therefore not a configuration task: it is what separates a tidy archive from one that works for you. ## Tricks that work when it will not turn up **En corto** - Search by who issued it, not by what you called it. - Try the reference number: official documents nearly always carry one. - And if you are after a date, search the month: everyone writes years differently. > [!NOTE] > If a value is asked for often and is not extracted, it is worth adding even if the old ones need a manual pass. That is half an hour recovered in the first month. **Can I search inside the document text?** Yes, and it helps; but an extracted value can also be watched and compared. **What if the document is a photo?** It reads the same, though check the value the first time. **Is it worth extracting everything?** No: only what you are asked. Extra extraction adds review with no use. ## Ejemplos **A company opens thirty policies to find which expire this quarter.** - Extracts the expiry on upload and queries the value instead of the document → The list appears in a second and warns on its own when one comes close. **What is needed is not a document but knowing whether something was done and when.** - Checks the file's history - Searches for the action rather than the file → The question is answered even though no paper answers it. **A document that never existed is hunted for.** - Checks whether what happened was a recorded action → You stop looking for what is not there. **You need to know who decided something.** - Checks that decision's log → The answer has a name and a date. **You need to prove that warning was given.** - Checks the send log → The warning is proved without a signed document. **A report nobody ever produced is requested.** - Checks the data and generates the report now → The answer exists even though the report did not. --- --- id: KB-TD-020 url: https://app.codecontract.io/help/day-to-day/logging-in-only-once-a-week idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-TD-008, KB-TD-009] citadoPor: [KB-TD-002] --- # Logging in only once a week _Not everyone lives in here. Whoever logs in on Fridays needs to see something different from the daily user._ **Responde a:** I log in rarely and get lost · catching up after a week · too many notifications piled up · occasional users Some people work in here every day and some log in on Friday afternoon to see how things are going: management, someone from another area, whoever covers quality alongside three other jobs. The inbox is built for the first group, which is why the second open it, see forty items and close it. ## What each one needs to see | Profile | What helps them | What is surplus | | --- | --- | --- | | Logs in daily | What changed since yesterday | The totals, which they know | | Logs in weekly | What is stuck and what is due | The detail of what is going fine | | Logs in monthly | Three numbers and the exceptions | Almost everything else | | Only when something happens | A direct link to that thing | The whole inbox | > [!IMPORTANT] > What makes someone stop logging in is not lack of time: **it is opening the inbox and not knowing where to start**. Forty unranked lines read the same as none, and by week three that person is asking things by phone — precisely what you were trying to avoid. For occasional users, order matters more than content: what has stalled first, then what is due, and what is going fine need not appear at all. ## What to set up for the occasional user 1. **A saved view with what is stalled and what is due** — The first thing they see on entry, not something to hunt for. 2. **A summary that reaches them by email** — Many will not log in; let the information go to them. 3. **And direct links in the alerts** — An alert should land on the exact item, not the home page. > [!WARNING] > Beware the natural reaction of sending more alerts to whoever logs in least: **if someone does not log in, they will not read twenty emails either**. What works with those profiles is the opposite — one message a week, with three things, and nothing at all if nothing is unusual. A summary that always arrives, even when all is well, stops being read just like the inbox that got closed. ## When the occasional user is the decision-maker **En corto** - They need exceptions, not activity: what has departed from plan. - And one stable figure they can compare with last month's. - If they have to interpret a list, they will not: someone has to summarise. > [!NOTE] > If someone logs in so rarely that the screen needs explaining every time, perhaps they do not need to log in: they need their part delivered to them. That is a design decision, not a training one. **Should I give them extra permissions so they do not get lost?** No: they get lost through what they see, not what they cannot. **What if they return after a month away?** Start with overdue and stalled; the rest can be skipped. **Is a view per person worth it?** Per profile, not per person: three views cover everyone. ## Ejemplos **A manager logs in on Fridays, sees forty unranked lines and stops logging in.** - Gets a view with what is stalled and due, plus a weekly email summary → They check in weekly again and stop phoning to ask what was already on screen. **Somebody who logs in once a week finds eighty changes and does not know where to start.** - Turns on the weekly digest instead of the daily one - Starts with what is waiting on their side - Leaves the informational for last, or for never → The weekly visit pays off in twenty minutes rather than a morning. **An expiry is missed by only logging in on Mondays.** - Configures the warning with enough lead time → The warning arrives even without daily logins. **Notices pile up unread between visits.** - Groups the informational ones into a digest → What requires action stands out. **A supplier waits six days for a reply.** - Shares the urgent items with somebody who logs in daily → The outsider does not wait a week. **You log in weekly and review everything.** - Uses a saved view of what matters → The visit starts where it should. --- --- id: KB-TD-004 url: https://app.codecontract.io/help/day-to-day/the-daily-digest idioma: en categoria: trabajo-diario subcategoria: bandeja audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-001, KB-TD-002] citadoPor: [KB-TD-009] --- # The daily digest _One email a day with what is there, instead of forty separate alerts._ **Responde a:** daily activity digest · one email with everything pending · too many alerts group them · automatic daily report If alerts reach you one by one as things happen, within two weeks you are ignoring them. The daily digest does the opposite: one a day, at the time you choose, with what is actually there. ## What it carries **En corto** - What arrived since yesterday and awaits review. - What is stuck and who it is waiting on. - What expires soon. ## Why it works better than separate alerts | Separate alerts | Daily digest | | --- | --- | | They interrupt when something happens | It is read when you decide | | Forty a day get ignored | One a day gets opened | | They do not say what is urgent | It is ordered by what matters | > [!IMPORTANT] > The digest does not replace alerts for urgent things. A rejected document or a case that unblocks does deserve an interruption; the rest can wait until tomorrow morning. The combination that works is few immediate alerts plus a digest for everything else. > [!WARNING] > Generating the digest consumes once a day; sending it consumes nothing, whether it goes to one person or twenty. It is a fixed, predictable consumption, but worth knowing before enabling it. > [!NOTE] > Set it for first thing, not end of day. A digest arriving at seven in the evening gets read tomorrow, and by then there is another. **Can I choose what it includes?** Yes, and you should: a digest with everything becomes noise again. **Does everyone get the same one?** Each person receives their own, based on what is theirs. **What about weekends?** It can be adjusted; a Sunday digest rarely helps. ## Ejemplos **A six-person team receives separate alerts and nobody opens them any more.** - Keeps immediate alerts only for rejections and unblocks - Enables the digest at 8am → They find out what is happening again, with one email a day instead of forty. **Somebody logs in three times a day to check whether anything moved.** - Turns on the daily digest with what changed - Sets the time to when it actually gets read - Leaves out anything not requiring action → Three daily visits become one thirty-second email. **The digest arrives at six in the morning and is read at midday.** - Adjusts the send time → The digest arrives when action is possible. **The digest includes everything and fills two screens.** - Leaves only what requires action → The digest gets read in full. **The digest arrives and nobody knows what to do with each line.** - Includes a direct link to each file → You act from the digest itself. **The digest arrives while on holiday.** - Pauses the digest or redirects it to the deputy → The digest reaches somebody who can act. --- --- id: KB-IC-001 url: https://app.codecontract.io/help/reports-and-quality/getting-out-the-numbers-you-have-to-show idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-003, KB-TL-009] citadoPor: [KB-IC-003, KB-IC-006, KB-IC-008, KB-IC-011, KB-IC-020] --- # Getting out the numbers you have to show _What can be measured, for whom, and which number does not mean what it looks like._ **Responde a:** documentation reports · how many cases are complete · get statistics for management · measure documentary compliance Sooner or later someone asks for numbers: how many suppliers are up to date, how long onboarding takes, how many cases are incomplete. The platform holds them all; the work is choosing the three that say something. ## The four that nearly always matter | Number | What it answers | For whom | | --- | --- | --- | | Complete cases over the total | Whether the control works | Management | | Average days to complete | Whether the process is reasonable | Whoever runs it | | How many expire next quarter | What is coming | Operations | | How many have been stuck over a month | Where the dead work is | Whoever runs it | > [!IMPORTANT] > "Complete cases" does not mean "compliant suppliers". A case can be complete with documents that expired last month if nobody set their expiry. Before showing that number to management, check the expiry dates are in place. ## The number that misleads Total documents. It only ever rises, means nothing, and creates a sense of progress that corresponds to nothing. An archive with twenty thousand documents, half of them expired, is worse off than one with two thousand current. > [!WARNING] > Be careful comparing months without knowing what happened. A month with few onboardings may be good news (no new suppliers) or bad (nobody processed them). The number alone does not say. > [!NOTE] > If you have to show this monthly, produce it the same way on the same day. A comparable report is worth far more than an exhaustive one. **Can it be exported to a spreadsheet?** Yes, with its dates, which is what lets you cross it with your own data. **Can it be filtered by site or client?** Yes, and that is usually the view people actually use. **Can a monthly report be automated?** Ask about it; for recurring reporting it usually pays off. ## Ejemplos **Management asks for a monthly documentary compliance indicator.** - Picks complete cases and next-quarter expiries - Checks first that expiry dates are set → The indicator reflects reality instead of counting expired documents as fine. **Management asks for the quarter's numbers and they are built by hand from three spreadsheets.** - Checks the status already calculated per period - Compares with the previous quarter before presenting - Saves the view so next quarter is not rebuilt → The report goes from an afternoon to ten minutes, and the next one costs the same. **The number rises and nobody can explain why.** - Compares the breakdown with the previous period → The change is located before the meeting. **Each department presents its figure and they do not reconcile.** - Checks the same source for all of them → The meeting starts from a common picture. **A number is shown without saying where it comes from.** - Brings the breakdown that backs it → The figure can be defended. **Something nobody uses to decide is measured.** - Keeps the indicators that change decisions → The report gets read in full. --- --- id: KB-IC-002 url: https://app.codecontract.io/help/reports-and-quality/recording-a-non-conformity idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-003, KB-CS-007, KB-IC-019] citadoPor: [KB-IC-004, KB-IC-005, KB-IC-007, KB-IC-009, KB-IC-012] --- # Recording a non-conformity _What went wrong, what was done, and how to prove it later._ **Responde a:** record a non-conformity · quality incident management · corrective actions iso · auditor asks for non-conformities A non-conformity is not a failure to hide: it is proof the system detects things. What an auditor views badly is not that they exist — it is that none are recorded, or that they are all still open. ## What you must be able to show 1. **What happened and when it was detected** — With dates. The gap between occurring and being detected is itself an indicator. 2. **What was done immediately** — The correction: stopping the batch, redoing the work, telling the client. 3. **Why it happened** — The cause, not the culprit. A record that names people stops being filled in. 4. **What was changed to prevent recurrence** — The corrective action, with an owner and a date. 5. **Whether it worked** — The closure. Without it, the non-conformity stays open forever. > [!IMPORTANT] > The step most often skipped is the last. A register full of non-conformities open for two years is worse than none: it demonstrates that things are detected and not corrected, which is the opposite of what it was meant to show. ## What is worth attaching **En corto** - Photos or documents from the time, certified if they may be disputed. - The communication to the client or supplier, if there was one. - Evidence that the corrective action was carried out. > [!WARNING] > If the non-conformity affects a client or a third party, telling them is part of the correction and often has deadlines. Do not leave it until everything is analysed. > [!NOTE] > Write the cause in a sentence that names nobody. "The procedure did not say who reviewed it" can be fixed; "Juan missed it" cannot. **Does it serve for an ISO audit?** It is exactly the register asked for, with its dates and evidence. **What about ones that come to nothing?** Close them noting no action was required. Closing is part of the record. **Who should be able to raise them?** The more people the better. A non-conformity only a manager can raise goes unraised. ## Ejemplos **An auditor asks for the non-conformity register and finds thirty open for two years.** - Closes those no longer applicable, noting why - Assigns an owner and date to the five real ones → The register turns from evidence against them into what shows the system works. **A non-conformity is noted in an email and three months later nobody knows if it closed.** - Records it in the file with an owner and a date - Notes what action was agreed and by when - Checks monthly which ones are still open → The non-conformity stops living in an inbox and either closes or explains why not. **It is recorded without saying what caused it.** - Notes the cause alongside the fact → The analysis starts from something. **They all get closed the day before the audit.** - Reviews them on their own cadence → Closing means something. **The same non-conformity repeats and nobody notices.** - Checks the history by type → The pattern shows and the cause gets tackled. **An auditor asks for the history and it has to be reconstructed.** - Checks the record with its dates → It is handed over without reassembling anything. --- --- id: KB-IC-003 url: https://app.codecontract.io/help/reports-and-quality/the-report-for-an-auditing-customer idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-001, KB-CF-003] citadoPor: [KB-IC-006, KB-IC-010, KB-IC-016] --- # The report an auditing customer asks for _What to show, in what format, and what not to send by email._ **Responde a:** compliance report for a customer · my customer audits me what do i send · documentary evidence for a customer audit · supplier report for a customer A large customer auditing you does not want a pretty report: they want to verify that what you say is true. That changes what you send and, above all, how. ## The three blocks they actually want | Block | What it demonstrates | | --- | --- | | Current status | How many of your suppliers are up to date, with the real number | | How you control it | That there is a process, not a review when someone remembers | | What happened when it failed | That you detect and correct, with concrete cases | > [!IMPORTANT] > The third block separates a credible report from a cardboard one. Nobody believes a report where everything is perfect: showing two non-conformities detected and closed demonstrates the control works far better than a spotless hundred per cent. ## Link or export If they only need to verify, give scoped read access: they see what they need, what they looked at is logged, and no copy of your data sits in their inbox. Exporting is for when they must keep it. > [!WARNING] > Do not email a report with your own suppliers' documentation inside. That is third-party information they never authorised you to share with your customer, and it is overlooked far too easily. ## What makes next year's audit go the same way **En corto** - Producing it identically each time, so it is comparable. - Numbers coming from the system, not from a separate spreadsheet. - Being able to show the detail behind any figure if asked. > [!NOTE] > If the same customer audits you annually, build their questionnaire as a process. What they ask changes little, and the second time costs an afternoon. **Can I give access only to their part?** Yes, scoped to the audited scope. **Is what they consulted recorded?** Yes, with date and time. **What if a figure does not add up?** Better to say so before they find it: explaining it yourself is worth far more than justifying it afterwards. ## Ejemplos **A company sends its customer a report showing 100% of suppliers up to date.** - Adds the two non-conformities detected and closed that year → The auditor believes it, and the conversation moves from checking figures to discussing improvements. **A client asks for a quarterly compliance report and it is prepared by hand each time.** - Checks the period's already-calculated data - Saves the format as a template - Schedules it to go out by itself → The quarterly report stops taking an afternoon and goes out even in a busy week. **Each client asks for the same figure in a different format.** - Checks once and adapts on sending → The underlying work happens once. **The report is sent and there is no record of what went out.** - Records what was sent, with its date → It can be compared with next quarter's. **The report includes other clients' data.** - Reviews the scope before sending → Information does not cross. **The client asks about a figure in the report and it has to be hunted.** - Keeps the breakdown with the report → The question is answered in minutes. --- --- id: KB-IC-004 url: https://app.codecontract.io/help/reports-and-quality/getting-ready-for-a-certification idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-002, KB-CF-003, KB-IC-013] citadoPor: [KB-IC-005] --- # Getting ready for a certification _The six months before, and what can be built meanwhile._ **Responde a:** prepare for an iso certification · first certification audit what do i need · documentation to get certified · how long does certification take Getting certified for the first time frightens people more than it costs, for one specific reason: they think everything has to be documented. It does not. What is checked is that you do what you say you do, and that it can be proven with dates. ## What actually gets looked at | What the auditor wants to see | What they do not care about | | --- | --- | | That there is a written process and it is followed | That the document looks nice | | That records are dated and were not filled in afterwards | That there are many records | | That you detect failures and close them | That there are no failures | | That people know what they have to do | That they know it by heart | > [!IMPORTANT] > What fails most is not missing documents: it is records all filled in the week before the audit. A perfect log in the same handwriting and the same ink across twelve months is spotted by any experienced auditor, and from then on they distrust everything else. ## What to build in the six months before 1. **The records filled in continuously** — Certified periodically, so their date does not depend on you. 2. **Supplier control** — With expiries marked, which is what shows monitoring rather than an annual glance. 3. **The non-conformity register** — Even if nearly empty. An empty one is suspicious; one with three detected and closed is evidence in your favour. 4. **Training for whoever does each thing** — With its date and its expiry. > [!WARNING] > Do not build processes you will not follow just to look good at the audit. A written procedure nobody follows is worse than none: the auditor asks the people, not only reads the paperwork. > [!NOTE] > The first certification costs; renewals cost much less. If what you build genuinely works, the second audit is showing what is already there. **Do I need to document everything?** No. What the standard requires and what you genuinely do; documenting what you do not do only creates problems. **Are digital records acceptable?** Yes, and with a trusted date they carry more weight than paper. **How long does it take?** It depends on the standard and your starting point; ask your certification body before fixing a date. ## Ejemplos **A company prepares its first certification by filling in twelve months of records in two weeks.** - Stops - Starts certifying the records month by month from now - Delays the audit by six months → Arrives with credible records instead of twelve months in the same ink. **A month remains before the certification audit and six months of evidence is missing.** - Checks which controls have no record - Prioritises what depends on third parties - Starts recording what is done daily from now → The month goes on closing specific gaps rather than generating paper after the fact. **Certification is prepared by creating documents for the occasion.** - Records what is actually done → The evidence describes the real company. **Certification passes and the following year starts from zero.** - Keeps the record current through the year → Renewal is a review. **The auditor asks for evidence of a control and is shown the manual.** - Shows the log of real operations → The control moves from assertion to evidence. **Nobody knows which controls each record covers.** - Notes which control each one answers → Preparation stops being a search. --- --- id: KB-IC-005 url: https://app.codecontract.io/help/reports-and-quality/when-a-supplier-keeps-failing idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-002, KB-IC-004] citadoPor: [KB-IC-007, KB-IC-012, KB-CR-014, KB-IC-013] --- # When a supplier keeps failing _From an isolated incident to a decision: when there is a pattern and what to do with it._ **Responde a:** supplier repeatedly failing · supplier evaluation incidents · when to stop working with a supplier · supplier incident history One failure is a failure. Three from the same supplier in six months are not: they are a pattern, and the difference between seeing it and not is having the history together rather than spread across three people's memories. ## How a pattern shows | Signal | What it usually means | | --- | --- | | Always late with the same item | They do not have it, and get it when pushed | | Fails when their contact person changes | The problem is their organisation, not their willingness | | Delivers expired documentation | They do not check it before sending | | Fails only on one site or with one client | It is a local problem, not the supplier's | > [!IMPORTANT] > The last row is the most overlooked. Before concluding a supplier is bad, check whether they fail with everyone or only in one place: if it is one, the problem may be how they are being asked from there. ## What to do with the pattern 1. **Show it to them** — With specific dates, not "you are always late". Most correct course once they see the list. 2. **Adjust what you ask for** — If the same document always fails, check whether you are asking for it well. 3. **Decide, and write it down** — Continue, continue with conditions, or stop. All three are valid; not deciding is not. > [!WARNING] > Be careful scoring suppliers with a number and no context. A supplier with three incidents in three hundred deliveries is not worse than one with one in four, and a badly built score ends up punishing whoever does most work for you. > [!NOTE] > When the decision is to stop working with someone, the dated history is what sustains it if that company objects. Without it, it is your impression against theirs. **Should I show the supplier the history?** It is usually the most effective step: most do not know there is a pattern. **How many incidents make a pattern?** It depends on volume. What matters is the proportion, not the count. **What if they are indispensable?** Then the decision is to continue with conditions, and those are worth writing down. ## Ejemplos **A company is about to drop a supplier over repeated incidents.** - Checks the history: all of them come from one site - Reviews how requests are made from there → The problem was that site's process, and the supplier stops failing without changing supplier. **A supplier fails for the third time and the conversation happens without data.** - Checks their incident history before meeting - Brings the dates and the impact of each - Agrees a plan with a review date → The conversation stops being an impression and the supplier knows what is measured. **Suppliers are switched without knowing whether the new one will be better.** - Compares both histories → The decision is taken with data. **Each department has its own view of how that supplier is doing.** - Checks the same source for all → The company speaks with one voice. **A plan is agreed and nobody reviews it.** - Sets the review date when agreeing it → The plan is met, or you know it is not. **The supplier improves and nobody acknowledges it.** - Checks the period's trend → The relationship matches what is happening now. --- --- id: KB-IC-006 url: https://app.codecontract.io/help/reports-and-quality/measuring-whether-control-is-improving idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-001, KB-IC-003] citadoPor: [KB-TL-017, KB-IC-017, KB-IC-018] --- # Knowing whether this is improving _Three numbers that tell the truth, and two that mislead._ **Responde a:** how do i know if document control is improving · document management indicators · measuring compliance improvement · supplier documentation kpi Six months in, the question appears: is this working? An honest answer needs three numbers, and there are two people watch that say nothing. ## The three that do say something | Number | What it reveals | Which way it should go | | --- | --- | --- | | Average days to complete a case | Whether the process works | Down, then stabilise | | How many complete with nobody phoning | Whether automatic chasing works | Up | | How many expired items exist right now | Whether control is real or on paper | Zero, and stay there | > [!IMPORTANT] > The second is what genuinely measures whether this is giving you time back. A case completing in ten days but with four phone calls along the way has saved nothing: it has only moved the work. ## The two that mislead **En corto** - Total documents: it only rises and means nothing. - Percentage of complete cases: it can be high because you close the hard ones incomplete. The second is the more treacherous, because it looks like the natural indicator. If it rises while cancelled cases also rise, what is improving is your willingness to give up, not your control. ## When to look Quarterly, not weekly. These numbers move slowly and watching them daily only generates noise and hasty decisions about variation that is chance. > [!WARNING] > Always compare with the same period last year, not with last month. Almost every sector has seasonality, and a poor August against July says nothing. > [!NOTE] > If a number will not make you change anything, do not measure it. A dashboard with fifteen indicators nobody uses is more work than information. **How often should they be reviewed?** Quarterly. Monthly while you are mid-change. **Can they be broken down by team?** Yes, and sometimes that is where you see the problem is local. **What if they get worse?** It often means volume grew or you are now measuring what you could not see before. Not always a bad sign. ## Ejemplos **A company celebrates that 92% of its cases are complete.** - Also checks how many were cancelled incomplete that quarter → Finds the percentage rises because hard ones get closed, and switches to days-to-complete instead. **People say this is going better and nobody has a figure to back it.** - Picks two or three indicators and measures them consistently - Compares with the same period last year - Notes what changed in between so it can be explained → The improvement is demonstrated rather than asserted, and you know what caused it. **Measurement starts at rollout and not before.** - Recovers the figure for how it was done before → The comparison has two points. **The indicator improves because the measurement changed.** - Keeps the criteria stable → The improvement is real rather than methodological. **Ten things are measured and nothing is decided.** - Keeps the ones that change decisions → The report gets read and used. **The indicator worsens one month and panic sets in.** - Looks at the trend rather than the point → The reaction is proportionate. --- --- id: KB-IC-007 url: https://app.codecontract.io/help/reports-and-quality/internal-audit-without-the-theatre idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-002, KB-IC-005] citadoPor: [KB-IC-009, KB-IC-010, KB-IC-014, KB-CR-019] --- # The internal audit, without the theatre _Its job is finding problems before someone else does. If it finds none, something is wrong._ **Responde a:** how to run an internal audit · what to review in an internal audit · internal audit programme · internal audit findings Internal audit has a problem built in: it is done by someone from the house, who knows everyone and knows what to look at to avoid awkwardness. That is how it ends up a formality that finds nothing and serves nothing. ## The sign it has become theatre **En corto** - It finds no findings, or always the same three harmless ones. - Two weeks' notice is given and everyone tidies up first. - The report is written before the looking is finished. > [!IMPORTANT] > An internal audit that finds nothing does not prove all is well: it proves nobody is looking. And it is worse than not doing one, because it also creates the false comfort that it has been checked. ## What to look at so it serves | Area | The useful question | | --- | --- | | Suppliers | How many have something expired right now? | | Records | Were they filled in when things happened, or afterwards? | | Training | Who is doing something their training expired for? | | Non-conformities | How many have been open over six months? | | Access | Are there accounts for people who left? | All five are answered with a filter, not an interview. That is the difference between auditing and asking whether everything is fine. > [!WARNING] > Do not turn findings into a list of culprits. An internal audit used to point at people stops receiving information the following year: people tidy up for the photo and the problem stays underneath. > [!NOTE] > Findings you make yourselves are worth more than an external auditor's, because they arrive earlier and count in your favour. Finding four things internally is a good result, not a bad number. **How often should it be done?** Annually at minimum; twice a year while mid-change. **Can the person running the area do it?** Better not: people audit their own work badly, however well intentioned. **Does it have to be documented?** Yes, with its findings and their closure. An unrecorded audit did not happen. ## Ejemplos **A company runs its annual internal audit and never finds anything.** - Replaces the questions with five concrete filters - Has someone from another area run it → Finds seven things, five are fixed that week, and the external audit passes without surprises. **The internal audit is prepared the week before by creating records after the fact.** - Audits against what is genuinely recorded - Notes findings with an owner and a date - Reviews at three months whether they closed → The internal audit serves to find things rather than to pass an exam. **Everything is audited each time and there is never enough time.** - Rotates the areas across periods → Each area is examined properly when its turn comes. **Findings are noted and nobody closes them.** - Checks the open ones monthly → The list goes down. **The internal auditor audits their own area.** - Swaps areas between auditors → The finding is credible. **An audit happens and there is no record of what was reviewed.** - Records the scope and what was examined → The audit is demonstrable. --- --- id: KB-IC-008 url: https://app.codecontract.io/help/reports-and-quality/what-to-show-at-the-monday-meeting idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-001, KB-TD-005, KB-IC-016] citadoPor: [KB-IC-011] --- # What to show at the Monday meeting _Three figures and a list of names. Everything else is surplus._ **Responde a:** what do i take to the weekly meeting · weekly documentation report · reporting status to my manager · summary for the management committee The temptation in a meeting is to show everything that was done. What works is the opposite: three figures that give context, and a list of concrete names something can be decided about today. ## What to take | What | What it is for in the meeting | | --- | --- | | How many cases closed this week | Sets the pace, without debate | | How many have been stuck over a month | The only number demanding action | | What expires in the coming weeks | Anticipates everyone's work, not just yours | | The three or four names needing a decision | What will actually be discussed | > [!IMPORTANT] > The last row is the only indispensable one. A meeting where figures are shown and nothing is decided is a report read aloud; what justifies it is leaving with three decisions taken on concrete cases. ## What not to take **En corto** - Cumulative document totals, which only rise. - Weekly trend charts, which show noise. - The detail of what is going well, which needs no meeting. > [!WARNING] > Be careful taking only what is going well. A meeting where there are never problems stops receiving information: people learn that difficult things are not raised there, and you hear about them when they can no longer be fixed. ## How to prepare it in five minutes With a saved view per figure and one for the list of names. If preparing the meeting takes half an hour every week, that is half a working day a year spent assembling something you could have ready. > [!NOTE] > If management asks for a monthly report, produce it identically on the same day. A comparable report beats an exhaustive one, because it shows the trend without arguing about method. **What if they ask for more detail?** Show it on the spot; what you should not do is bring everything just in case. **Does it work for several teams?** Each with their own; merging everything dilutes the decisions. **How often should the meeting be?** Weekly for operations, monthly or quarterly for figures. ## Ejemplos **A manager spends half an hour each Monday preparing a report nobody uses to decide.** - Keeps three saved views and one list of names → The meeting moves from reading figures to taking three decisions, and preparation drops to five minutes. **Monday's meeting starts with everyone giving their own version of how things are going.** - Opens the same view for everyone - Starts with what has been stalled too long - Leaves the meeting with an owner and a date per item → The meeting goes from forty minutes of catching up to fifteen of decisions. **Ten indicators are shown and nothing is decided.** - Shows the two or three that change decisions → The meeting produces agreements. **The figure shown does not match another department's.** - Checks the same source → The argument is about what to do rather than what is true. **Everything is reviewed and the urgent runs out of time.** - Starts with what is blocking somebody → What unblocks goes first. **What was agreed in the meeting is recorded nowhere.** - Records the agreements as tasks → The following Monday starts from there. --- --- id: KB-IC-009 url: https://app.codecontract.io/help/reports-and-quality/analysing-why-something-happened idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-002, KB-IC-007] citadoPor: [KB-IU-008, KB-IC-014, KB-IC-019] --- # Analysing why something happened _The difference between fixing a case and fixing the cause._ **Responde a:** root cause analysis · why does the same failure repeat · effective corrective action · investigating an incident A failure is fixed in minutes: the document is redone, the supplier is phoned, the send is repeated. What is hard is stopping it recurring, and for that you need to know why it happened — which is almost never what it looks like at first sight. ## Going down a level, three times The technique is simple: ask "and why?" three times about the previous answer. Almost always the third produces something changeable, while the first produces only a person. | Level | Typical answer | What can be done with it | | --- | --- | --- | | First | "Someone forgot" | Nothing. That is a name, not a cause | | Second | "There was no way to know it was due" | Now you can work with it | | Third | "That document had no expiry marked" | This is fixable, and for everyone | > [!IMPORTANT] > If the conclusion of an analysis is a person's name, the analysis is not finished. People make mistakes; what you are looking for is what allowed that mistake to produce consequences with nothing stopping it earlier. ## How to check the fix worked 1. **Define what should stop happening** — In one concrete, measurable sentence, not "improve control". 2. **Set a date to look** — Three months is usually enough to know whether it recurs. 3. **Close only then** — Closing on the day the fix is applied is closing without knowing whether it worked. > [!WARNING] > Beware the corrective action that consists of asking someone to be more careful. That is not a corrective action: it is the same situation with a more pressured person, and it fails identically on the first bad day. > [!NOTE] > Analyses that work usually end in a small, dull change: marking an expiry, changing a request title, assigning an owner. Those ending in a new ten-page procedure rarely change anything. **Does it have to be done for every incident?** No. For those with consequences and those that repeat. **Who should do it?** Someone not directly involved, if possible. **What if the cause is outside our company?** Document it the same: the action is then about the relationship with that third party. ## Ejemplos **A company concludes that an insurance policy lapsed "because the purchasing lead missed it".** - Goes down two more levels: that document type had no expiry marked → Fixes the configuration and the problem can no longer recur with anyone, not just her. **Something happens and the analysis is done from memory two weeks later.** - Checks the recorded sequence with its dates - Identifies which specific step failed - Records the cause and the action with a review date → The analysis starts from facts and the action can be verified months later. **A culprit is sought instead of a cause.** - Looks at which process step allowed it → The action corrects the process rather than a person. **The cause is identified and nothing changes.** - Records the action with an owner and a date → The analysis produces a change. **The same problem returns six months later.** - Checks whether it had happened before → The cause is tackled rather than the symptom. **The analysis ends up in a document nobody opens.** - Records it in the incident's file → It is found when it is needed again. --- --- id: KB-IC-010 url: https://app.codecontract.io/help/reports-and-quality/proving-compliance-without-showing-the-documents idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-003, KB-IC-007] citadoPor: [KB-LE-008, KB-AD-011, KB-NO-014, KB-IC-015] --- # Proving compliance without showing the documents _A client wants assurance; your contracts with third parties are not theirs to read._ **Responde a:** prove compliance without handing over contracts · a client asks to see confidential documents · certify without exposing supplier data · compliance evidence without sharing files It happens as soon as you work with someone large: they ask to see your suppliers' documentation. And you cannot show it in full — it carries prices, terms and third-party data that are not yours to share. ## The distinction that solves it What they are asking for is not the document: it is assurance that it exists, is current, and that someone checked it. Those are different things and they can be separated. | What they ask for | What they actually need | What you hand over | | --- | --- | --- | | "Send me the contracts" | To know there is a contract with everyone | How many, how many current, since when | | "I want to see the insurance" | To know cover exists and has not lapsed | Status and expiry date, not the policy | | "Show me the certificates" | To know they are up to date | The certificate yes; what surrounds it, no | | "I need to audit" | To check the control exists | The check history, with dates | > [!IMPORTANT] > The fourth row is the most valuable and the least used. The record that a check **happened**, with a date and a name, usually satisfies an auditor better than the document itself — because it proves the process, not one isolated case. ## How to prepare it 1. **Produce the status, not the files** — How many current, how many pending, how many expired. 2. **Add the date of the last check** — That is what turns a list into evidence. 3. **Show one complete example, with permission** — Just one, from a supplier who agrees, so they see the rigour. 4. **And state in writing what you do not share and why** — "Third-party data" is a reason people understand, and it closes the conversation. > [!WARNING] > Do not do the opposite: set up a shared folder with everything in it "so they see we hide nothing". That turns a trust problem into a data protection one, and that one has consequences. ## When they still insist If the client demands the full documents, ask the affected suppliers one by one. Some will agree. Those who refuse have given you exactly the answer you need to justify it. > [!NOTE] > A sealed document allows something more: a third party can verify that the file you are showing is exactly the one that existed on the date you claim, without taking your word for it. **Does it count as formal evidence?** For most client audits, yes. For a certification, it depends on the standard. **Can I give limited access instead of files?** Yes, and it is usually better: they see theirs and nothing else. **What if the client demands we keep their data?** That is a different matter and belongs in the contract, not the report. ## Ejemplos **An industrial client demands to see the contracts with all thirty subcontractors.** - Hands over the documentary status with check dates - Shows one complete file with that subcontractor's permission → The client considers the requirement met and no third-party data leaves the organisation. **A client wants to verify compliance and is sent forty documents containing third-party data.** - Shows the control record instead of the documents - Shares only what answers their question - Records what was shared → The client verifies what they need without receiving information that was not theirs. **The whole file is sent for convenience.** - Selects what matches each point → Nothing extra is handed over. **The client asks to see documents containing personal data.** - Offers the control evidence instead → You demonstrate without exposing third parties. **A screenshot is shown and the client does not accept it as proof.** - Shares with controlled, verifiable access → The client verifies rather than believes. **The access granted stays open after the review.** - Revokes it on completion → The information does not stay exposed. --- --- id: KB-IC-011 url: https://app.codecontract.io/help/reports-and-quality/the-monthly-report-in-ten-minutes idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-008, KB-IC-001] citadoPor: [KB-CR-013, KB-IC-017, KB-IC-020] --- # The monthly report in ten minutes _Three figures, one comparison and one sentence. The rest is padding._ **Responde a:** monthly compliance report · what to put in the monthly quality report · reporting document status to management · quick monthly report The monthly report eats a whole morning and almost nobody reads it. Usually because it tries to tell everything, when the reader only needs three things: whether we are doing well, whether anything is getting worse, and whether something needs deciding. ## The structure that works 1. **Three figures, always the same ones** — Changing metrics every month makes comparison impossible, which is the point. 2. **The comparison with last month** — A lone number says nothing. "84%" does not inform; "84%, three points down" does. 3. **One sentence of why** — The explanation of what moved. It is the only part no dashboard can produce. 4. **And what you need from the reader** — Ask for nothing and the report is decorative. Ask for something and it becomes a useful meeting. > [!IMPORTANT] > The fourth point separates a report that gets read from one that gets filed. "Two suppliers have gone sixty days without supplying; I need purchasing to decide whether to hold their orders" is a report that produces a decision. ## Which three figures to choose | Figure | What it says | Why that one | | --- | --- | --- | | Percentage current | The general state | Everyone understands it without explanation | | Average time taken | Whether the process is improving | It moves before the percentage falls | | Open cases and their age | Where it hurts now | It points at this month's actual work | > [!WARNING] > Do not add fifteen indicators because they are available. Each one reduces the chance anyone looks at the three that matter, and none of the fifteen will produce a decision. ## What does not need explaining **En corto** - What is fine and unchanged: one line is enough. - Case-by-case detail: in an annex or nowhere. - And what was already decided last month, unless it was not done. > [!NOTE] > If the report comes from what is already recorded, it takes minutes and always uses the same criteria. If it has to be assembled by hand, besides being slow, each month is calculated slightly differently and comparisons stop meaning anything. **What if management wants more detail?** Send the detail they asked about, not everything just in case. **Does the same report work for a client?** The format yes; the content no: a client wants theirs, not your overall. **Monthly or weekly?** Monthly for management, weekly only if something needs correcting as you go. ## Ejemplos **A quality manager spends a morning on the report and nobody ever comments.** - Cuts it to three fixed figures, the comparison and one concrete request → The report gets read, and for the first time produces a purchasing decision. **The monthly report takes a whole afternoon of copying and pasting.** - Checks the period's already-calculated status - Saves the format as a template - Schedules it to generate itself → The report goes from an afternoon to ten minutes and goes out even on a busy day. **The report arrives on the 15th and is no longer useful.** - Schedules it for the first working day → The figure arrives while action is still possible. **The format changes every month and comparison is impossible.** - Keeps the same format → Month-to-month comparison makes sense. **The report includes everything and nobody reads it all.** - Keeps the indicators that change decisions → The report gets read. **A figure in the report is queried and it has to be rebuilt.** - Keeps the breakdown with the report → The question is answered in minutes. --- --- id: KB-IC-012 url: https://app.codecontract.io/help/reports-and-quality/raising-a-quality-claim-with-a-supplier idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-002, KB-IC-005] citadoPor: [KB-CS-032, KB-IU-007, KB-DI-016] --- # Raising a quality claim with a supplier _What has to be gathered before writing the claim, not after._ **Responde a:** supplier claim for defective product · documenting a supplier non-conformance · claiming for defective material · evidence for a supplier claim A quality claim is won or lost in the first few hours, before anything is written. What decides it is not the wording: it is what was gathered while the problem was in front of you and could still be documented. ## What to gather the same day 1. **The batch and its intake documentation** — Delivery note, certificate, receipt date. It ties the defect to that supply. 2. **Photos of the defect and of the whole** — Detail and context: a close-up with no context identifies nothing. 3. **How much is affected** — Whether it is the whole batch or part, and how you checked. 4. **And the real impact** — Line stoppage, rework, missed delivery. It is what quantifies the claim. > [!IMPORTANT] > The fourth is barely ever documented in time and is the only one that turns a complaint into a claim. "The material was bad" opens a technical argument; "the material was bad and stopped the line for six hours" opens a negotiation. ## What to have in place beforehand | Element | Why beforehand | | --- | --- | | An agreed written specification | Without it, "bad" is an opinion | | Acceptance criteria at goods-in | It defines what is checked and to what tolerance | | The supplier's incident history | It changes the conversation if this is the third time | > [!WARNING] > The third row carries the most weight and survives the worst, because incidents usually live in different people's emails. Held in the supplier's file, the claim stops being an isolated case and becomes a pattern, which is a different conversation. ## When writing it **En corto** - Dated facts, not judgements. - What you want, concretely: replacement, credit, deadline. - And the response time you expect. > [!NOTE] > Communicating with proof of delivery matters more here than elsewhere: defect claim windows are usually short and run from receipt or from detection, depending on the case. **What if the defect appears months later?** You can still claim, but what was recorded at goods-in weighs heavily. **Should we return the material before it is resolved?** Not without agreeing: returning the evidence early complicates proving the defect. **Should an internal non-conformance be raised too?** Yes, and linked: the claim looks outward, the non-conformance inward. ## Ejemplos **A factory receives out-of-spec material and claims a week later.** - Gathers batch, photos, affected quantity and impact the same day - Links the supplier's incident history → The claim is settled with replacement and no technical argument, because the facts were dated. **A supplier is challenged on quality and replies that it is the first time.** - Checks their incident history with dates - Provides the specific impact of each - Agrees a plan with a review date → The claim rests on facts and the supplier knows exactly what is being asked. **The complaint is made by phone and nothing remains.** - Records it with what was agreed → What was agreed stops depending on two memories. **The complaint comes late and the deadline has passed.** - Records the incident on detection → The claim goes out in time. **A complaint is made and nobody checks whether it improved.** - Sets the review date when complaining → The plan is met, or you know it is not. **The supplier improves and is still treated the same.** - Checks the period's trend → The relationship matches what is happening now. --- --- id: KB-IC-013 url: https://app.codecontract.io/help/reports-and-quality/the-trial-period-for-a-new-supplier idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-005, KB-CR-014] citadoPor: [KB-IC-004] --- # The trial period for a new supplier _Six months to find out whether they work, with criteria decided before starting._ **Responde a:** approving a new supplier · supplier trial period · criteria to evaluate a supplier · when to stop working with a supplier A new supplier almost always comes in on price or urgency, and their evaluation is left to the general impression of whoever deals with them most. Six months later nobody can say whether they work better or worse than the previous one, because nobody decided in advance what would be looked at. ## The four criteria that suffice | Criterion | How it is measured | When to worry | | --- | --- | --- | | Meets deadlines | On-time deliveries over the total | If it worsens after the first deliveries | | Meets specification | Quality incidents per delivery | Any repeat of the same defect | | Responds on documents | Days to supply what is requested | More than a week on average | | And warns when something is wrong | How many problems they told you before you saw them | If the answer is zero | > [!IMPORTANT] > The fourth is not measured in numbers and best predicts how the relationship will go. A supplier who warns of a delay three days ahead is worth more than one who hits 98% and tells you about the 2% when the lorry does not arrive. ## How to run the period 1. **Write the criteria before the first delivery** — Four, with thresholds. Written afterwards, they get written to justify the conclusion you already had. 2. **Record incidents as they happen** — In their file, not in the memory of whoever suffered them. 3. **Review at three months, not only at the end** — That is when it can still be corrected; at the end you only decide. 4. **And close with a written decision** — Approved, approved with conditions, or not. All three are valid answers. > [!WARNING] > The awkward case is the supplier who performs but is hard to work with. If that is not among the criteria, the decision will still be taken on that basis, only without being explainable — and that conversation with the supplier cannot then be had. ## What makes the period useful **En corto** - That the supplier knows they are on trial and against what criteria. - That incidents are raised as they happen, not at the end. - And that the decision comes on the planned date, not when someone remembers. The first changes the outcome most: a supplier who knows they are being evaluated, and how, behaves differently — and that is information about them too. > [!NOTE] > The same scheme suits an external collaborator, a subcontractor or an advisory firm. What is measured in criterion two changes; the other three are identical. **Always six months?** Long enough for ten or twelve deliveries. Two tell you nothing. **What if they fail on the first delivery?** Record it and raise it; one bad delivery does not decide, repeating it does. **Is formal approval required?** It depends on your quality scheme; a written decision is worth having anyway. ## Ejemplos **A company brings in a supplier on price and six months later argues about keeping them.** - Writes four criteria before the first delivery - Reviews at three months and raises two incidents → The final decision is made on data and the supplier knew from the start what was being measured. **A new supplier enters a trial period and nobody defines what will be looked at.** - Sets what will be measured and for how long - Records every delivery and every incident - Reviews at the end with the data in front of you → The decision to continue is taken on facts rather than an impression. **The period ends and nobody decides anything.** - Sets a review date at the start → The trial period genuinely ends. **Continuing is decided by inertia.** - Checks the record before deciding → The decision is taken on a basis. **The supplier does not know they are on trial.** - Tells them and shares what will be measured → The supplier gets a chance to succeed. **The supplier is dropped and there is no record of why.** - Records the reason for closing → The decision is explicable months later. --- --- id: KB-IC-014 url: https://app.codecontract.io/help/reports-and-quality/when-the-audit-finds-something idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-007, KB-IC-009] citadoPor: [KB-TZ-016, KB-IC-019] --- # When the audit finds something _A finding is not a failure. What is: the same finding two years running._ **Responde a:** responding to an audit finding · corrective action plan · audit non-conformity what do i do · closing a finding The usual reaction to a finding is to fix the specific case and reply that it is corrected. It works for closing the paperwork and guarantees the same thing appears next year, because what was fixed was the symptom. ## The three levels of response | Level | What is done | What happens next year | | --- | --- | --- | | Fix the case | The missing document is sorted | It reappears, with a different document | | Fix the cause | What made it go missing is changed | It does not return, if that was the cause | | Check it does not return | Look again after three months | It genuinely closes | > [!IMPORTANT] > The third level separates a system that works from one that reacts. A finding closed without later verification is not closed: it is waiting to be rediscovered. ## How to respond well 1. **Accept the finding if it is correct** — Arguing when they are right costs credibility for when they are not. 2. **Look for why it happened, not who did it** — It is nearly always a process asking for something operations could not give. 3. **Set an action with an owner and a date** — An action without a name and a date is an intention. 4. **And verify afterwards, with evidence** — Three months later, looking at data rather than impressions. > [!WARNING] > Beware the disproportionate corrective action. Adding three new controls for a minor finding creates a process nobody follows, and next year's finding will be that your invented controls are not followed. ## What to have from last year **En corto** - The previous findings and what was done about each. - Evidence that they were verified. - And if any repeated, said openly. An auditor who sees a repeated finding acknowledged and explained judges very differently from one who discovers it themselves by comparing reports. > [!NOTE] > The commonest findings on third-party documentation are always the same three: something expired undetected, something approved unchecked, and something that cannot be evidenced even though it was done. All three share a root. **What if the finding is unfair?** Answer with evidence, not arguments. With the data, it falls by itself. **How long is there to respond?** Whatever the scheme sets; the sensible pattern is immediate action and deferred verification. **Should minor findings be recorded?** Yes: they are the ones that repeat and that foreshadow serious ones. ## Ejemplos **A company closes a finding by uploading the missing document.** - Looks into why it was missing and finds nobody owned the alert - Verifies three months later → The finding does not repeat the following year, which was the real goal. **The audit leaves fourteen findings and six months later nine are still open.** - Records each finding with an owner, an action and a date - Checks the open ones monthly, not the week before the next audit - Closes with evidence of what was done, not with a «done» → The next audit finds nine fewer findings, and those remaining have dates. **Every finding is closed the day before the follow-up audit.** - Spreads the closing dates across the period - Reviews progress halfway through → Closure reflects a real change rather than a three-day sprint. **A finding is assigned to a department and nobody specific picks it up.** - Assigns it to a named person - Checks they have the permissions to close it → There is somebody to ask, and somebody who can act. **The finding is closed and the same problem reappears a year later.** - Notes the cause as well as the correction - Checks whether that finding had come up before → You tackle what produces it rather than what is visible. **The auditor asks for evidence of closure and is shown an email.** - Attaches the evidence of what was done to the finding → Closure is demonstrated rather than asserted. **Minor findings nobody prioritises end up blocking certification.** - Marks which ones condition the certification → Effort goes to what actually blocks. **A finding you disagree with is accepted anyway.** - Records the disagreement with its reasoning → The position is documented for the next audit. --- --- id: KB-IC-015 url: https://app.codecontract.io/help/reports-and-quality/when-your-client-wants-to-audit-your-supplier idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-010, KB-NO-008, KB-CR-019] citadoPor: [KB-IC-019] --- # When your client wants to audit your supplier _Three parties, two contracts and an awkward question: how far your duty to disclose reaches._ **Responde a:** my client wants to audit my supplier · second-tier supply chain audit · they ask for data about my subcontractors · how far must i disclose my chain It happens more and more: a large client is not content auditing you, they want to see who supplies you too. The request is legitimate and the answer is not automatic, because your supplier has no contract with your client — they have one with you. ## The three ways to respond | Way | What it involves | When it fits | | --- | --- | --- | | You answer on their behalf | You show your control over that supplier, not their documents | Most cases | | The supplier answers directly | With their consent, and knowing what is being asked | When the client demands traceability to origin | | On-site audit by the client | Requires all three parties to agree | Regulated sectors or large contracts | > [!IMPORTANT] > The first usually settles it and is the least attempted. What your client needs to know is not what your supplier's certificate says: it is that **you request it, check it and act when it is missing**. You can evidence that from your own record without showing a single third-party document. ## What to agree before it is asked 1. **What you may share about your suppliers** — Ideally agreed in your contract with them, not improvised under pressure. 2. **What your client requires contractually** — Sometimes the obligation to give chain access is already signed and nobody has read it. 3. **Who talks to whom** — Letting your client contact your supplier directly without you brings commercial problems that are not worth it. 4. **And what happens if the supplier refuses** — It is a real possibility and it helps to have decided whether that forces a change of supplier. > [!WARNING] > The risk almost nobody sees coming is commercial, not documentary: if you put your client in direct contact with your supplier, you have introduced them. In sectors where the intermediary supplies the relationship rather than the product, that has cost entire accounts. Not a reason to refuse, but a reason to decide it deliberately rather than in a hurried email. ## What can be shown without exposing anyone **En corto** - How many suppliers you have in that category and how many are current. - What you require from them and how often you renew it. - When the last check happened and who did it. - And what you do when one fails, with a real anonymised case. That last point convinces more than any list: showing that last year you blocked a supplier over expired documentation proves the control genuinely exists. A percentage does not prove that. > [!NOTE] > Certification schemes and supply-chain requirements vary widely by sector and by client, and they change. **What you are obliged to provide and what you are not is a conversation for your adviser and your contract**, not something to infer from the client's request — which will always ask for the maximum. **Can I refuse?** It depends what you signed. If it is not in the contract, it is negotiable. **What if my supplier does not want to?** That is useful information: a supplier who cannot evidence what you require is also your risk. **Is showing my supplier's certificate enough?** It helps, but it only proves that document. What defends you is the ongoing control. ## Ejemplos **A large client demands to audit the subcontractor making a component.** - Shows its own control over that subcontractor with check dates - Agrees with the supplier what may be shared before replying → The client considers the requirement met with no direct contact between the two companies. **A client announces they want to audit your transport supplier and nobody knows what can be shown.** - Checks what you agreed with that supplier about third-party audits - Warns the supplier before the request reaches them - Shares only what concerns that client → The audit is arranged without damaging the supplier relationship or over-disclosing. **The client asks to audit and the supplier contract does not provide for it.** - Negotiates it with the supplier before committing them - Writes the outcome down for future contracts → The commitment to the client is realistic and the supplier is not ambushed. **Supplier documentation is handed over containing their other clients' data.** - Reviews the content before sharing → Nothing is leaked that was not yours to give. **Three clients want to audit the same supplier.** - Gathers what is asked and negotiates a single audit → The supplier receives one visit, not three. **The audit finds something and nobody knows who answers.** - Writes down beforehand who owns which finding → The action plan has an owner from day one. **The audit happens and there is no record of what was shown.** - Records the bundle handed over, with its date → The handover is demonstrable afterwards. **The supplier refuses and the client reads it as opacity.** - Offers the control evidence instead of the document → The client verifies without the supplier exposing what they should not. --- --- id: KB-IC-016 url: https://app.codecontract.io/help/reports-and-quality/the-report-an-insurer-asks-for idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-003, KB-LE-007] citadoPor: [KB-IC-008] --- # The report an insurer asks for _After an incident, what decides the payout is not what happened: it is what you can show from before._ **Responde a:** documentation for an insurance claim · the loss adjuster asks for documents · insurance claim required documentation · what to keep in case of an incident When an incident happens — damage, an accident, a theft, a serious breakdown — the conversation with the insurer is not about the event: it is about whether the conditions you signed up to were being met. And that is proven with documentation from before the event, which is exactly what nobody prepares with this in mind. ## What a loss adjuster asks for, in order | What they ask for | What they are checking | From when it must date | | --- | --- | --- | | The policy and its endorsements | What was covered that day | In force on the date of the event | | Maintenance and inspections | That the policy's obligations were being met | From before, with their dates | | Documentation of third parties involved | Whether subcontractors were there and with what cover | From before | | What happened | The event itself | From the moment: reports, photos, notifications | > [!IMPORTANT] > The first three rows are from **before** the incident and they are what decides. A serviced extinguisher, a certified installation or a subcontractor with current insurance cannot be evidenced afterwards: either the dated paper existed or it does not. The fourth row — what happened — is what everyone gathers and what nobody much disputes. ## What to do in the first hours 1. **Record the event with its time, even with gaps** — A report written the same day is worth far more than a complete one three days later. 2. **Photograph before touching anything** — Once cleaning or repair starts, the scene stops being reconstructable. 3. **Notify within the policy's deadline** — And keep proof of that notification, not just make it. 4. **And gather the before-material while you still remember where it is** — Inspections and the contracts of whoever was involved. > [!WARNING] > Point three is where most claims get complicated, and not on the merits: many policies set a short window to report an incident, and reporting through a channel that leaves no trace amounts to arguing later about whether you did. A notification with delivery evidence the same day closes that door for good. ## What to have in place before you need it **En corto** - Mandatory inspections with warnings, which are exactly the ones that lapse unnoticed. - Each subcontractor's insurance, current and checked, not filed. - Condition photos of what is delivered or received. - And the policy where someone can find it at nine at night. That last looks minor and is not: incidents rarely happen in office hours, and the first half hour goes on finding what is covered and who to call. > [!NOTE] > Reporting deadlines, what each policy covers and what documentation it requires vary by contract and by line of business. **Confirm that with your broker or in the policy itself**; what is described here is what to keep findable so that conversation is short. **What if the maintenance was done but not recorded?** You try to evidence it with whatever exists — invoices, technician reports — but it weighs far less. **Is a phone photo enough?** Yes, and better with a provable date if the amount is significant. **Should the adjuster be given access?** Handing over what they ask for is usually enough; if they will review a lot, read-only access is easier for both. ## Ejemplos **A company has a warehouse fire and the adjuster asks for fire system inspections.** - Hands over the dated inspections and the current insurance of the subcontractor working there → The claim proceeds on the facts, with no argument about whether conditions were met. **After a claim, the insurer asks you to evidence three years of document control.** - Checks the period's history with its dates - Provides the record of checks performed, not a description - Records what was handed over and when → The claim rests on a verifiable trail rather than on a statement. **The insurer is answered with a description of the procedure.** - Shows the log of real operations → The control moves from assertion to evidence. **The record for exactly the period of interest is missing.** - Documents the search and its outcome → A proven absence is worth more than silence. **The insurer asks for something inside documents containing third-party data.** - Shares the control evidence instead → You demonstrate without exposing anyone. **The policy covered less than was assumed.** - Checks what was contracted before claiming → Expectations are set before the conversation. **The claim goes in late because documentation had to be hunted.** - Keeps the file current through the year → The claim goes in within time. **Each department sends its part to the insurer separately.** - Centralises the response in one file → The insurer receives a coherent set. --- --- id: KB-IC-017 url: https://app.codecontract.io/help/reports-and-quality/when-the-numbers-get-worse idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-011, KB-IC-006, KB-IC-020] citadoPor: [KB-IC-018] --- # When the numbers get worse _Reporting a bad figure is easy with a cause and a plan attached, and very hard if reported late._ **Responde a:** how to report worsening indicators · delivering bad news in a report · explaining a figure that dropped · the percentage fell what do i say One month the percentage falls, cycle time rises, or three incidents appear where there were none. The temptation is to wait another month in case it corrects itself. That wait is what turns a figure into a problem. ## The three ways to report it, and what each produces | How it is reported | What it produces | | --- | --- | | Not at all, hoping it recovers | When it surfaces, it surfaces two months old and unexplained | | The figure alone | Questions, alarm and an unplanned meeting | | The figure, the cause and the plan | A decision, which was the point | > [!IMPORTANT] > The difference between the second and third is not tone: **the third closes the gap distrust comes through**. A worsening number with no explanation leaves the reader imagining the cause, and what they imagine is usually worse than reality — normally something about your management rather than a supplier who failed. ## How to prepare it in ten minutes 1. **Separate a case from a trend** — Four stuck files are not a deteriorating process, and saying so prevents an unnecessary reorganisation. 2. **Find the cause before writing** — It is nearly always there: a staff change, a new supplier, a workload spike. 3. **Say what you have already done** — Even if little: the reaction counts as much as the figure. 4. **And what you need, if you need anything** — It is what turns a bad figure into a reasonable request. > [!WARNING] > The case to be clear about: **if the figure worsened because you started measuring better, say so explicitly**. It is the commonest and least understood: recording incidents that previously went unrecorded makes them rise, and a reader without that context concludes quality has fallen exactly when control improved. That nuance is not visible in the chart. ## What does not work **En corto** - Comparing against an unusually good month to soften it. - Changing the metric in the very month it worsens. - And promising it will be fixed next month without knowing why it happened. All three get spotted, and all three cost credibility for every later report, including the good ones. > [!NOTE] > If the figure worsens two months running for the same reason and nothing has been decided, the problem is no longer the figure: it is that the report is not being used to decide, which was its only purpose. **What if I do not know the cause?** Say that: "I do not know yet, I am looking into it" is professional; inventing one is not. **Should I warn before the meeting?** If it is serious, yes. Nobody wants to find out in front of others. **What if the cause is a person?** The report covers the process; the conversation about the person is separate and not public. ## Ejemplos **A manager sees incidents rise right after starting to record them all.** - Explains it in the report: they rise because they are now recorded, not because there are more → Management reads the figure as better control rather than falling quality. **The share of complete files drops from ninety to seventy-two per cent in two months.** - Compares the breakdown with the previous period to see where it comes from - Separates whether the drop is one supplier, one area or everyone - Checks whether anything in the process changed in between → The drop is explained by a specific cause rather than becoming a meeting of recriminations. **The number worsens because forty new suppliers came in with no file.** - Separates the new book from the established one → The indicator stops penalising growth. **The indicator worsens one month and the whole process is changed.** - Looks at six months of trend before touching anything → The reaction is proportionate to the problem. **It worsens and everyone is asked to try harder.** - Checks which specific step has lengthened → Effort goes where the bottleneck is. **The way of measuring changed and nobody said so.** - Notes any change of criteria with its date → The series stays comparable. **The figure worsens and stops being shown.** - Presents it with the cause and the plan → The indicator keeps supporting decisions. **One particular person drags the team's number down.** - Checks the detail before drawing conclusions → Overload is told apart from a performance problem. --- --- id: KB-IC-018 url: https://app.codecontract.io/help/reports-and-quality/when-the-metric-rates-people idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-006, KB-IC-017] citadoPor: [KB-IC-020] --- # When the metric rates people _The moment a number rates someone, it stops measuring what it measured. Not through bad faith: by design._ **Responde a:** metrics to rate the team · the dashboard does not reflect reality · per-person quality targets · how to stop numbers being massaged A dashboard showing how many files close on time is useful while it serves to see where work gets stuck. The day that same number enters the appraisal of whoever runs those files, it starts to move — and not because the work improved. ## What happens to each metric once it rates people | Metric | How it is «improved» without improving anything | | --- | --- | | Files closed on time | They are closed before they are complete, then reopened | | Incidents logged | Fewer get logged: recording one penalises whoever records it | | Average response time | A quick «we are looking into it» that answers nothing | | Documents verified | The easy ones get verified and the doubtful ones parked | > [!IMPORTANT] > The second row is the dangerous one and the least anticipated: **when logging a problem hurts whoever logs it, problems stop being logged**. The dashboard improves, reality does not change, and you lose the very information that fixed things. It is the one case where a metric can leave you worse off than measuring nothing at all, because it also breeds confidence. ## How to measure without breaking the measure **En corto** - Process metrics look at the process: bottlenecks, not people. - What goes upwards, aggregated; the individual part belongs in the conversation, not the dashboard. - And spotting a problem early is recognised, not penalised: that is what saves you the trouble. > [!WARNING] > There is a tell that exposes the problem before results show it: **a metric that improves without anyone having changed anything**. If the percentage climbs one month and nobody can explain what was done differently, what usually changed is how things get recorded, not the work. It is worth ten minutes in the detail: those ten minutes decide whether the dashboard is still good for anything. ## What is worth looking at per person 1. **Load, not performance** — How many files each carries; useful for sharing work out. 2. **Blockers outside their control** — Anything waiting on an outside answer is nobody's fault inside. 3. **And what repeats in one specific place** — If a step always jams with the same person, it is usually the step. > [!NOTE] > If the metric will feed an appraisal or pay, there are employment and data protection implications that depend on your country and your collective agreement. **Check that with your adviser before switching it on**, not after. **So people are not measured?** They are accompanied. An isolated figure without conversation is always read wrong. **How do I know this is already happening?** Look for a metric that improves without anyone knowing why. **What if management asks for a ranking?** Give the aggregate and explain the effect. Showing it once usually suffices. ## Ejemplos **A company adds «incidents logged» to the quality team's monthly appraisal.** - Takes it out of the appraisal and keeps the metric on the process dashboard only → Small incidents get logged again, and those are the ones that warn before the big one. **Files closed per person starts being measured and the team starts closing things half done.** - Also measures the quality of what is closed, not just the count - Checks how many get reopened afterwards - Shares the criteria before starting to measure → The indicator stops rewarding speed and starts describing the real work. **The indicator compares whoever handles easy suppliers with whoever handles hard ones.** - Separates by file type before comparing → The comparison is honest. **The number is used in appraisals without ever being explained.** - Explains what it measures and what it does not before using it → Nobody first learns how they are measured at their appraisal. **One person scores badly and they were the only one covering absences.** - Checks the detail before drawing conclusions → Context is taken into account. **The indicator improves because incidents stopped being recorded.** - Checks the record is still complete → The improvement is real rather than one of recording. **People are measured when the problem is the process.** - Checks whether the bottleneck is one person's or everyone's → The process is fixed rather than people pressed. **The team stops reporting problems to avoid scoring badly.** - Separates the management indicator from the appraisal one → Problems keep surfacing while they can still be fixed. --- --- id: KB-IC-019 url: https://app.codecontract.io/help/reports-and-quality/the-corrective-action-that-never-closes idioma: en categoria: informes-y-calidad subcategoria: calidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-014, KB-IC-009, KB-IC-015] citadoPor: [KB-IC-002] --- # The corrective action that never closes _Opened at the audit, worked on for two weeks, then left. And the same finding returns the following year._ **Responde a:** corrective actions open for months · how to close a non-conformity · the auditor repeats the same finding · proving the action worked Any company with a quality system has a list of corrective actions, and in almost all of them three or four have been open for over a year. It is not neglect: closing them properly demands something the daily rush does not allow, and that nobody explains. ## The three ways not to close an action | What was done | What is missing | What happens next | | --- | --- | --- | | The specific case was fixed | The cause is still there | It happens again with another document | | The action was written but not done | The doing | The auditor finds it in two questions | | It was done but not recorded | The evidence | It is as if it never happened | | It was closed the same day it was done | Checking that it worked | It closes falsely, and this is the commonest | > [!IMPORTANT] > The fourth row is what makes the finding return: **an action does not close when it is carried out, it closes when it is shown to have worked**. Between the two, enough time must pass for the problem to have reappeared if the cause were still alive. Closing the same day documents an intention, not a result — and an auditor comparing this year's report with last year's spots it effortlessly, because the finding is literally the same. ## What each action needs before it can close 1. **What happened, in one sentence** — Without hunting for culprits: that is what kills the analysis. 2. **Why it happened, honestly** — «An oversight» is not a cause; it is where people stop looking. 3. **What changes so it does not return** — If the change relies on someone remembering, it is not a change. 4. **And when it will be checked** — A future date, with an owner, which is what allows closure. > [!WARNING] > There is a pattern worth recognising early: **if an action has been open a year, it is almost never for want of work — it is because nobody knows what would be needed to call it closed**. Nobody touches it for fear of getting it wrong. In those cases pressing harder does not help; ten minutes writing down what evidence would suffice does, and often that evidence already exists. ## When the auditor repeats the finding **En corto** - A repeated finding weighs far more than a new one: it says the system does not react. - Acknowledging it before they raise it changes the conversation entirely. - And a well-documented action, even a slow one, proves exactly the opposite. > [!NOTE] > What each certification scheme requires on deadlines, format and closure evidence is set by the standard that applies to you and by your auditor. **Your quality manager or adviser settles that**; here it is about a closed action genuinely meaning it will not come back. **How long should we wait to check?** As long as the process takes to repeat: a full cycle, not a week. **Can several close with one action?** Yes, if they share a cause. And if they do, say so: it is a good sign. **What if the cause is outside our control?** Document it anyway, with what is within your reach. ## Ejemplos **A company closes a corrective action the same day it fixes the affected document.** - Sets a check date one cycle ahead and closes it with evidence it did not recur → The finding stops repeating at the next audit, which was the point. **A corrective action has been open fourteen months and nobody remembers what opened it.** - Checks the finding that originated it and its date - Decides whether it still makes sense or must be closed with an explanation - If it stands, sets an owner, a specific action and a date → The list of open actions becomes credible again and those remaining have owners. **The action is so general it can never be finished.** - Splits it into steps with their own dates → Each step can genuinely be closed. **It is closed without evidence and the auditor reopens it.** - Attaches the evidence of what was done on closing → The closure holds up. **The action depends on an investment nobody has approved.** - Records the blocker and who must decide → The blocker has an addressee instead of sitting inside the action. **The owner left eight months ago.** - Reassigns open actions when somebody leaves → None is orphaned. **They are all reviewed the week before the audit.** - Reviews them monthly → Closure spreads out and reflects real work. **There are thirty open actions and no priority.** - Marks which ones condition a certification or a contract → Effort goes where it matters. --- --- id: KB-IC-020 url: https://app.codecontract.io/help/reports-and-quality/the-report-that-turns-into-a-monthly idioma: en categoria: informes-y-calidad subcategoria: informes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IC-011, KB-IC-001, KB-IC-018] citadoPor: [KB-IC-017] --- # The report that turns into a monthly _Someone asked once, liked it, and now it is expected monthly. What must be pinned down is not the result: it is the definition._ **Responde a:** asked for the same report every month · the numbers do not match last month · automating a recurring report · defining a metric properly Almost no recurring report starts life as one. It starts as a one-off request — «send me how many files we closed this month» — solved in an afternoon on personal judgement. The problem starts when that figure repeats: from the second time on, it is no longer compared with reality, it is compared with itself. ## What to pin down before repeating it | Decision | Why it matters | What happens if left open | | --- | --- | --- | | What counts as «closed» | It varies most between people | Each month is counted by whoever does it, their way | | Exactly what period it covers | Calendar month, four weeks, up to a cut-off | Months stop being comparable | | What is excluded | Tests, internal cases, cancelled ones | A month with tests looks like a good month | | Where each figure comes from | So it can be reproduced identically | Nobody can rebuild it when that person is away | > [!IMPORTANT] > The consequence nobody sees coming is the first row's: **if the definition is not written down, the report changes it silently every time someone else produces it**. And since the numbers look reasonable, nobody suspects; it simply turns out that this month «we improved». A recurring report is worth its comparison, so a drifting definition is not a methodological detail: it turns the whole history into something meaningless. ## How to stabilise it in twenty minutes 1. **Write the definition alongside the report, not elsewhere** — Two lines: what is counted, which period, what is excluded. 2. **Rebuild last month under that definition** — If it does not match what was delivered, better to know now. 3. **Note where each figure comes from** — It is what lets someone else produce it in August. 4. **And only then automate what can be automated** — Automating a loose definition multiplies the problem. > [!WARNING] > Before signing it off, it is worth asking what it is used for: **a report requested every month is rarely read in full, and sometimes only one figure gets looked at**. If out of five pages the only thing anyone reads is the number at the top, everything else is surplus — and that surplus is exactly what makes the report cost a morning. Asking once saves twelve mornings a year and usually reveals that two different reports are needed, not one big one. ## When the figure starts moving **En corto** - Before explaining the variation, check the definition did not change. - A sharp jump with nothing to explain it is usually a change of criteria, not of business. - And if you change the definition deliberately, rebuild the history or mark the break. > [!NOTE] > If the report leaves your company — to a client, an insurer, a regulator — the definition becomes part of the commitment: changing it later requires explaining it, so agree it beforehand with whoever receives it. **Can I change the definition if it was wrong?** Yes, flagging it and rebuilding what is comparable. Keeping quiet is what does not work. **What if each area counts differently?** Then they are different reports: separate them rather than averaging. **Should it be automated from the start?** No: automate once the definition has held still for two or three months. ## Ejemplos **A company delivers a monthly closed-files report and the figures stop adding up.** - Writes the definition alongside the report and rebuilds last month under it → It finds two people counted «closed» differently, and the history compares again. **A report requested once for a meeting becomes monthly without anyone deciding it.** - Checks who reads it and what it decides - Schedules it if it helps, retires it if not - Saves the format as a template so it is not rebuilt → The monthly report exists because somebody uses it, and costs ten minutes rather than an afternoon. **The report goes to fifteen people and two open it.** - Asks who wants to keep receiving it → The distribution list reflects who uses it. **Every month it is rebuilt from scratch.** - Saves the view and the format → The second month costs a fraction. **The report arrives on the 20th and is no longer useful for deciding.** - Schedules it for the first working day → The figure arrives while action is still possible. **The format changes monthly and comparison is impossible.** - Keeps the same format and the same criteria → The series shows the trend. **Nobody knows where the numbers come from.** - Keeps the breakdown with the report → Any question is answered in minutes. **The report grows to six pages.** - Keeps the indicators that change decisions → It gets read in full. --- --- id: KB-CL-001 url: https://app.codecontract.io/help/collaboration/sharing-a-space-with-someone-outside idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-008, KB-CO-013] citadoPor: [KB-CL-002, KB-CL-003, KB-CL-008, KB-CL-009, KB-CL-011, KB-CL-014, KB-CL-020] --- # Sharing a space with someone outside _When the back-and-forth with a third party lasts months and does not fit in one link._ **Responde a:** shared space with a client · working continuously with a supplier · shared folder with an external party · collaborate with a third party without full access Requesting documents with a link works when the relationship is one-off. When you will be exchanging things with that third party for months — a long project, a site, a client who sends material weekly — the link runs out of road. ## Link or shared space | Situation | What to use | | --- | --- | | You ask them for four documents once | A case with its link | | Continuous exchange over months | A shared space | | They also need to leave things for you | A shared space | | There are several people on each side | A shared space | ## What they see and what they do not **En corto** - They see what is in that space, and nothing else of your organisation. - Not other clients, other suppliers, or your internal notes. - They can leave things, not only collect them. > [!IMPORTANT] > A shared space is more convenient, which is why it is easier to over-share into it. Before uploading, ask whether that person has to see it: what goes into a shared space is seen by the other side, with no further filter. > [!WARNING] > When the relationship ends, close the space that day. It is the most forgotten step, because an open space bothers nobody — until it does. > [!NOTE] > If you work with several competing clients, one space per client is not tidiness: it is what stops one seeing another's material. **Does the outsider need an account?** For an ongoing space, yes; for a one-off case, no. **Can I see what they looked at?** Yes, accesses are logged. **Can a link become a space?** Yes, without losing what was already delivered. ## Ejemplos **A builder exchanges drawings and certificates with the same engineering firm for two years.** - Opens a shared space instead of sending separate links - Closes it when the project ends → Documents stop circulating by email and everything sits in one place with its dates. **A contractor shares a network folder with their advisers and ends up giving access to other clients' files.** - Shares the specific file rather than the folder - Limits access to read-only if they only need to consult - Revokes access when the engagement ends → The adviser sees what they need, there is a trail of what they opened, and access expires with the work. **Something is shared with an external party and nobody knows what they opened.** - Checks that file's access log → The question is answered with data rather than an assumption. **The external party asks for access to everything to avoid asking weekly.** - Grants what they need for their specific task - Extends later if needed, and it is recorded → Scope grows for a reason rather than for convenience. **The project ends and the consultant is still logging in six months later.** - Sets an expiry date when granting access → Access closes itself even if nobody remembers. **A link is shared by email and ends up forwarded to a third party.** - Shares with the person, not as an open link → Access stands in the name of whoever uses it. **The external party uploads documents and there is no record of who did.** - Records them as a named participant → Every contribution has an author and a date. **Two consultancies work on the same project and can see each other.** - Separates each one's scope → Each sees their own without crossing over. --- --- id: KB-CL-002 url: https://app.codecontract.io/help/collaboration/what-can-run-itself-and-what-cannot idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-005, KB-CL-001, KB-CL-019] citadoPor: [KB-CL-004, KB-CL-010, KB-CL-005, KB-CL-006] --- # What can run itself and what cannot _Where automation ends and a person becomes necessary._ **Responde a:** automate document management · what can be automated · what automated agents do · let the system work by itself The question that always comes is how much of this can be left running on its own. The honest answer: considerably more than people think on the repetitive side, and none of what decides. ## The boundary | Runs itself | Needs a person | | --- | --- | | Requesting the usual documents from the right people | Deciding whether a supplier is still worth keeping | | Chasing at days 3, 7 and 12 | The day-15 phone call, when chasing has stopped working | | Warning about expiries with margin | Negotiating the renewal | | Reading a document and extracting its dates | Deciding whether that document is acceptable | | Marking approved what meets every criterion | Approving what meets almost all of them | Notice the pattern: what can be automated is whatever has a clear rule. The moment a "it depends" appears, someone is needed. > [!IMPORTANT] > Do not automate approval of anything with consequences. Having the system mark as approved whoever meets every criterion is fine; having it approve whoever nearly meets them is delegating a decision that remains yours if something goes wrong. ## The reasonable target Not 100%. It is that 85% closes itself and people spend their time on the 15% that needs judgement — which is where a person actually adds something. > [!WARNING] > Be careful automating a process that is still changing. If the process is not stable, the automation breaks fortnightly and creates more work than it removes. > [!NOTE] > Before automating something, do it by hand three times. That is what shows you where the exceptions are, and exceptions are what break automation. **Can I review before something automatic goes out?** Yes, and it is wise at first: review, confirm it gets it right, then let it run. **Can everything be stopped if something goes wrong?** Yes, and it is worth knowing how before you need it. **Is what the system did recorded?** Yes, the same as what a person does. ## Ejemplos **A company wants to automate supplier approval end to end.** - Automates requesting, chasing and clearing whoever meets everything - Leaves the near-misses to a person → 85% closes itself and the exceptions are decided by someone who answers for them. **The reminder is automated and the team expects it to also decide whether a document is valid.** - Automates what needs no judgement: requesting, chasing, warning - Leaves approval with whoever has the judgement - Checks what is happening automatically before relying on it → The repetitive stops occupying anyone and what needs judgement still has an owner. **Approval is automated and expired documents get through.** - Automates the date check and leaves the rest for review → What is checkable is checked automatically and what is doubtful reaches a person. **Nobody knows what the system is doing on its own.** - Checks which rules are active → The automatic behaviour is known. **A rule has been active a year and no longer makes sense.** - Reviews the rules when the process changes → The system does what the company needs today. **Something that happens twice a year is automated.** - Automates what repeats every week → Effort goes where there is repetition. **A rule is switched off and nobody knows what stopped happening.** - Notes what it did before switching it off → The gap is visible rather than discovered. **Two rules do the same thing and the supplier gets two notices.** - Checks for overlap before adding a new one → The recipient receives a coherent message. --- --- id: KB-CL-003 url: https://app.codecontract.io/help/collaboration/what-you-have-signed-for-others idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-005, KB-CL-001] citadoPor: [KB-CL-011] enLaApp: https://app.codecontract.io/participaciones --- # What you have signed or delivered to others _Your own history when someone else is the one asking, not you._ **Responde a:** where do i see what i have signed · documents i delivered to other companies · history of my signatures · find a document i signed a while ago Almost the entire help centre is written from the requester's side. But if you have an account and are also somebody's supplier, you are on the other side too: you sign contracts, deliver certificates, answer requests. All of that is your history as well. ## Why having it together helps **En corto** - Finding what you signed with a client two years ago, without asking them. - Seeing what someone is waiting on from you right now. - Knowing which of your documents are out there, and since when. ## What people look for here | Situation | What is sought | | --- | --- | | A client disputes an old agreement | The exact document signed, with its date | | Documentation has to be renewed with several clients | What was delivered to each and when | | Someone asks whether something was sent | The receipt, rather than memory | > [!IMPORTANT] > What you signed is signed by you and cannot be modified afterwards, exactly like what others sign for you. It is the same property seen from the other side, and worth bearing in mind before signing: what you accept stays accepted. > [!NOTE] > If you are both client and supplier to the same company, this shows half the relationship and your own cases show the other. They are two views of one deal. > [!WARNING] > Having an account does not mean you need one to respond to somebody. Your own suppliers do not need one, and it is better not to ask them for one. **Can I download what I signed?** Yes, with its evidence inside. **Does my team see it?** Depending on the permissions you have set. **Can a document I signed be verified?** Yes, on the public page, like anyone else's. ## Ejemplos **A company needs an agreement it signed with a client three years ago and no longer has the email.** - Looks it up in its own participation history → Retrieves it with its evidence without asking the client, who is precisely who they are arguing with. **A client asks for copies of everything signed over two years and it has to be hunted across four inboxes.** - Checks the history of what was signed and delivered to that client - Checks which version of each document they received - Delivers from the platform so there is a record → The handover is prepared in an afternoon and it is on record exactly what they received and when. **A different version from the one signed is handed over.** - Checks which version carried the signature → Both parties hold the same document. **The client says they never received something that was sent.** - Checks the send and delivery dates → The dispute closes on the record. **A search by file name returns nothing.** - Searches by content or by client → It is found without depending on what it was called. **Nobody knows what has been delivered to each client.** - Checks the history per client → The picture exists without reconstructing it. **A document is resent and the second delivery is not recorded.** - Records each send with its date → The history reflects every occasion. **The client asks for the copy years after the relationship ended.** - Retains the history per the retention policy → The request is met without depending on a lost folder. --- --- id: KB-CL-004 url: https://app.codecontract.io/help/collaboration/agents-that-work-and-when-they-ask-you idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-002, KB-MA-004] citadoPor: [KB-CL-006, KB-CL-007] enLaApp: https://app.codecontract.io/agents --- # Agents: what they do alone and when they ask you _Work that advances without you, with a stopping point where a person decides._ **Responde a:** what do ai agents do · automated work that pauses to ask · review what an agent did · do agents consume credits An agent is work that advances without you present: it prepares, checks, sorts and completes whatever has clear rules. What makes it usable is not that it is fast — it is that it stops when a decision is due. ## The states you will see | State | What it means | What to do | | --- | --- | --- | | Running | It is working | Nothing | | Awaiting human | It reached something it does not decide | Look at it: that is where the person adds value | | Pending review | It finished and wants confirmation | Review and approve or correct | > [!IMPORTANT] > "Awaiting human" is not a failure: it is the design. An agent that never stopped would be taking decisions that remain yours if something goes wrong. The more it stops early on, the more reliable it is when you let it run. ## How to start without surprises 1. **Review everything at first** — For the first runs, approve by hand. That is where you see whether it gets it right. 2. **Release what it always gets right** — Repetitive work with a clear rule can stop being reviewed. 3. **Do not release what decides** — Approving, rejecting or blocking someone remains a person's job. > [!WARNING] > It consumes credits, like any work using external services. If you leave one running over a large volume, check the balance first: it is the fastest way to exhaust it without noticing. > [!NOTE] > Everything it does is logged like a person's actions: what it did, when and on what. If something does not add up, it can be reconstructed. **Can I stop it?** Yes, and it is worth knowing how before you need to. **What if it gets something wrong?** It is corrected like any other change, and the correction is recorded. **Does it see more than I do?** No. It works inside your organisation and with its permissions. ## Ejemplos **A company leaves an agent preparing cases and reviews nothing for the first weeks.** - Goes back and approves the first batches by hand - Releases only the repetitive part once it proves reliable → Ends up with 80% prepared automatically and the decisions with whoever answers for them. **An agent is switched on and the team does not know what it does unprompted and what it checks first.** - Checks which actions it can take alone and which ask for confirmation - Starts with those that touch nothing outside - Reviews after a week what it did before widening → The agent is widened on observed behaviour rather than on an expectation. **The agent writes to a supplier with nobody reviewing it.** - Keeps anything leaving the company behind a confirmation → Nothing reaches a third party unseen. **The agent approves a document that had expired.** - Limits what it can approve on its own → Approving the doubtful stays human. **Nobody knows what the agent did this week.** - Checks its action log → Its behaviour is auditable like a person's. **The agent gets something wrong and nobody knows what it decided on.** - Checks what information it had in front of it → The error is fixed in the criteria rather than case by case. **It is given access to every file for convenience.** - Limits its scope to the process it serves → The agent sees just enough for its task. **It is switched on and nobody decides when to switch it off.** - Sets a review at four weeks → The decision to keep it is taken with data. --- --- id: KB-CL-008 url: https://app.codecontract.io/help/collaboration/working-with-a-consultant-or-external-specialist idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-001, KB-ET-008] citadoPor: [KB-CL-009, KB-LE-011, KB-CS-035, KB-CL-018] --- # Working with a consultant or external specialist _Someone external working inside: what to give them and what to recover at the end._ **Responde a:** give a consultancy access · working with an external specialist · consultant preparing our certification · temporary access for an external collaborator A consultant preparing your certification, a specialist building a process, an engineering firm running a project: outsiders who for months work as if they were inside. It is the relationship that closes worst and leaves the most accesses open. ## What they genuinely need | They need | They do not need | | --- | --- | | To see and create in the area they work on | To see the rest of the organisation | | To talk to your third parties if the engagement includes it | To be an administrator | | To leave the work done and documented | To keep access after the engagement | > [!IMPORTANT] > Set an end date from day one, even if you do not know when it finishes. Dated access gets renewed if needed; undated access is still open three years later, and nobody misses it because that person was never part of the team. ## What to agree beforehand 1. **What they take at the end** — Normally nothing. What they build stays in your organisation, not theirs. 2. **What they may show third parties** — If they will speak to your suppliers on your behalf, say so expressly. 3. **What happens to what they learned** — A consultant works for more companies in your sector. That is normal and worth bearing in mind. > [!WARNING] > If the consultant will handle your clients' or your workers' documentation, that is no longer just an access: third-party data is involved. Review it with whoever handles data protection before granting it. ## At the end **En corto** - Close the access that day, not when they invoice the last hour. - Check that what they built ends up with someone inside. - And that this someone knows how it works, not merely that it exists. > [!NOTE] > The costliest failure in these relationships is not the access left open: it is that the process the consultant built is understood only by them, and six months later nobody knows how to change it. **Can they work with our suppliers?** If the engagement includes it and it is clear to everyone, yes. **Do they see what other teams do?** Only if you give it. Scope them to their area. **Is what they did recorded?** Yes, under their name, like anyone else. ## Ejemplos **A consultancy builds the documentary system for a certification and finishes the engagement.** - Their access is closed that day - Someone inside walks through how it works with them → Six months later the team can change the process without re-engaging them. **A consultancy comes in to set the system up and still has administrator access six months after finishing.** - Grants the minimum access for their engagement - Sets an expiry date when granting it - Reviews at project close which accesses remain → The consultant works without friction and access closes itself when the work ends. **The external technician builds everything on their personal account.** - Uses a company service account → What was built outlives their departure. **They leave and nobody knows how they configured the process.** - Asks them to document the decisions before going → The team can touch it without fear. **The consultant sees client files outside their scope.** - Limits access to the project's files → They see theirs and nothing more. **They are asked for something out of scope and do it unrecorded.** - Records what was asked and what was delivered → The engagement is demonstrable. **They return a year later and their access was still active.** - Revokes access on closing → Access reflects who is collaborating today. **Nobody knows what they did during the project.** - Checks the log of their actions → The external party's work is auditable. --- --- id: KB-CL-009 url: https://app.codecontract.io/help/collaboration/when-your-client-uses-their-own-platform idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-001, KB-CL-008] citadoPor: [KB-CL-011, KB-CL-012] --- # When your client uses their own platform _Uploading the same thing to five different places, and how to stop duplicating._ **Responde a:** my client requires me to use their platform · uploading documents to several portals · every client has their own system · duplicating documentation for clients You work for five large clients and each has their own portal. All five ask for the same things — insurance, tax clearance, your people's training — and it has to be uploaded five times, with five different renewal calendars nobody keeps together. ## What to separate | What | Where it lives | Who maintains it | | --- | --- | --- | | Your actual documentation | Your case, once | You | | The copy on client A's portal | Their portal | You, uploading it | | The copy on client B's portal | Their portal | You, again | > [!IMPORTANT] > The mistake is treating the client's portal as where your documentation lives. It lives in yours; portals are copies, and when something is renewed all of them must be updated. If the original lives in five places, there is no original. ## How to stop duplicating the work 1. **One single case of your own** — With the good version of each document and its expiry marked. 2. **A list of where copies exist** — Which client's portal holds which document. Without that list, renewal always gets forgotten somewhere. 3. **On renewal, update all of them** — That is when it gets done, not when a client tells you something has lapsed. > [!WARNING] > An expired document on a client's portal can block your site access or your invoice, even if yours is current. For that client, the truth is what is on their portal. ## If the portal allows it Some clients accept a verification link instead of a copy. It is the best of both: they check on the spot and you stop maintaining copies. Ask: it is granted more often than it is requested. > [!NOTE] > If an agent can log into that portal to upload the documentation, this is one of the tasks where it pays off most — mechanical, repetitive and verifiable. **Can I give the client access instead of uploading?** It depends on their policy; worth asking. **What if each portal wants a different format?** Keep the original and adapt copies; never the reverse. **How many portals are too many?** Past three, without a list of where copies exist you will forget one. ## Ejemplos **A subcontractor renews its insurance and three weeks later a client blocks its site access.** - Keeps its own case with a list of portals holding copies - On renewal, updates all five → Stops discovering through blocked access that one was forgotten. **Five clients each have their own portal and the team maintains the same documentation in six places.** - Keeps a single current file of your own - Uploads to each portal from there, not from loose folders - Records what was uploaded to each and when → Renewal happens once and gets replicated, instead of being repeated five times in different versions. **A document is renewed and updated in only three portals.** - Checks which clients it must be replicated to → No client is left holding the old version. **Each portal asks for the same document under another name.** - Keeps the original and adapts on upload → The underlying work happens once. **The client's portal rejects the document without saying why.** - Asks the specific reason before re-uploading → The second attempt is aimed. **Nobody knows what expires in which portal.** - Records expiries in your own file → One warning covers every portal. **The client changes portal and everything starts from zero.** - Keeps your own file independent of the portal → The client's change does not cost you the history. **Two people upload different things to the same portal.** - Assigns an owner per client → The portal receives a coherent version. --- --- id: KB-CL-010 url: https://app.codecontract.io/help/collaboration/where-to-start-automating idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-002, KB-CL-005] citadoPor: [KB-CL-013, KB-CL-019] --- # Where to start automating _The first thing worth leaving to run itself, and why that one._ **Responde a:** what should i automate first · recommended first automation · where to start with automation · automating without complications The short answer is chasing: reminders at days 3, 7 and 12. It gives back the most time, can break the least, and needs no explaining. ## Why that one and not another | Criterion | Automatic chasing | | --- | --- | | How much time does it return? | A lot: it is the most repetitive work there is | | What if it fails? | Little: one reminder too many or too few | | Does anything need deciding? | No: it is a clear rule with no exceptions | | Is the effect visible? | Within two weeks, in delivery | > [!IMPORTANT] > The four answers together are what make it first. An automation that returns a lot but could break something serious is not first; one that breaks nothing but returns nothing is not either. ## The order for the rest 1. **Automatic chasing** — Spaced reminders. Week one. 2. **Expiry warnings** — With margins based on who renews each item. Week two. 3. **One of the dull rules** — Open a task when something has been stuck too long. 4. **And only then, the rest** — Once the first three have run a month with nobody touching them. > [!WARNING] > Do not start with what decides. Approving, rejecting or blocking someone are your decisions, and automating them before trusting the rest is the fastest way to have to backtrack. ## How to know it worked If two weeks later you have forgotten it exists, it is working. An automation you have to watch daily is solving nothing: it is moving the work from one place to another. > [!NOTE] > Every automatic action consumes just as if a person did it. A rule firing a thousand times spends a thousand: check the breakdown in the first month, not the sixth. **What if my case is different?** The criterion still applies: high return, little harm if it fails, no decisions. **Can I automate several things at once?** You can, and then you will not know which caused what. One at a time. **Can it be switched off?** Yes, at any moment. ## Ejemplos **A company wants to automate document approval to move faster.** - Starts with automatic chasing - Leaves approval with a person → Recovers most of the time without delegating any decision it answers for. **Automation starts with the company's most complex process.** - Starts with what repeats weekly and needs no judgement - Measures how much time it consumes today before touching it - Checks at four weeks whether the saving is real → The first automation pays for itself in a month and gives a basis for choosing the second. **Something that happens three times a year is automated.** - Counts the repetition before investing → Effort goes where it pays. **A process that still changes weekly is automated.** - Stabilises the process before automating it → The automation is not rebuilt monthly. **It is automated by copying the paper circuit, dead steps included.** - Removes steps that existed only because of paper → The new process is shorter than the one it replaces. **What decides is automated instead of what chases.** - Automates requesting, chasing and warning → The repetitive disappears and the judgement stays. **Nobody measures whether the automation helped.** - Compares against the time it used to take → The next decision is taken with data. **Five things are automated at once and none works well.** - Builds one, verifies it and moves to the next → Each is understood and can be fixed. --- --- id: KB-CL-011 url: https://app.codecontract.io/help/collaboration/a-project-with-several-companies-at-once idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-001, KB-CL-009, KB-CL-003] citadoPor: [KB-CL-018, KB-CL-020] --- # A project with several companies at once _A joint venture, a consortium or a shared site: who keeps what and who answers for it._ **Responde a:** joint venture documentation · project with several companies who keeps the documents · consortium shared documentation · working with a partner on a joint project When two or three companies join for a project, the first thing agreed is the split of work and money. What is almost never agreed is where the documentation lives — and that becomes a problem exactly when the project ends and everyone goes their own way. ## The three questions to close at the start 1. **Where does the project file live?** — In one place, not three. If each partner keeps their own, nobody holds the whole. 2. **Who sees what?** — Everyone sees the project; each company's internal material is not shared by default. 3. **What does each take away at the end?** — Decide beforehand. Afterwards the conversation is far more awkward. > [!IMPORTANT] > The third is always forgotten and causes the most trouble years later, when a claim arrives and what was done must be reconstructed. If nobody agreed who keeps the whole, each partner has a fragment and none can answer in full. ## How it is organised in practice | Layer | Who enters | What it holds | | --- | --- | --- | | The shared project | All partners | What affects the whole: contracts, minutes, deliveries | | Each partner's own | That company only | Their staff, their subcontractors, their costs | | Third parties | By their link, no account | Only theirs: what they sign or supply | > [!WARNING] > The expensive mistake is doing it backwards: opening one space where everyone sees everything "because we are partners". Each company's employment and cost documentation need not circulate, and sharing it creates obligations nobody meant to take on. ## What to record along the way **En corto** - Who supplied each document and when. - What was approved, by whom, and against which version. - And any communication that commits something, inside rather than in crossed emails. These three are what gets asked for if the project ends in dispute. They are free to record while it happens and impossible to reconstruct afterwards. > [!NOTE] > It applies equally to a joint-venture site, a research consortium, a shared development or a large engagement split between a law firm and a consultancy. The vocabulary changes, the mechanics do not. **What if each partner uses a different system?** Pick one for the shared project; internal work stays wherever each prefers. **Can access be limited to one phase?** Yes, and for occasional collaborators that is the sensible option. **Who pays for consumption?** Whatever is executed from the hosting organisation comes out of its balance; agree it alongside the rest of the split. ## Ejemplos **Two builders take on a site together and each keeps its own part.** - Open the shared project and keep internal material separate - Agree in writing who keeps the whole at the end → Four years later, facing a claim, there is a single complete file to turn to. **On a project with five companies, each sends their documentation to whoever they think best.** - Records each company as a participant with its scope - Assigns which document each one provides - Checks progress per participant rather than per inbox → Nobody duplicates or gets left out, and only those with something outstanding are chased. **One company can see the documentation of a competitor.** - Limits each participant's scope → Each sees their own. **All five are chased when one is missing.** - Chases only whoever is outstanding → Those who complied receive no reminders. **Two companies upload the same document.** - Makes clear who provides what from the start → Duplicated work is avoided. **The project ends and the accesses stay active.** - Revokes access on closing → The file is not left open to five companies. **A company subcontracts and an unexpected participant appears.** - Records which companies are authorised → The list of who participates is known. **Nobody knows who provided what when a problem arises.** - Checks the participant record → The question is answered with a name and a date. --- --- id: KB-CL-012 url: https://app.codecontract.io/help/collaboration/when-the-other-side-will-not-change idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-009, KB-CC-012, KB-CL-020] citadoPor: [KB-CL-016, KB-CR-020] --- # When the other side will not change _The supplier who only sends emails and the client who insists on their portal. Both have a way through._ **Responde a:** the supplier refuses to use the platform · the client forces us onto their portal · working with people still on email and spreadsheets · adapting to a client's tool No organisation works alone, and not everyone will use the same thing. There are two distinct situations — those who will not change and those who impose their system on you — and they are solved differently. ## Case 1: the supplier still on email The key point is that they **do not have to change tools**. No account, no password, nothing to learn: they receive a request, enter by their link, upload from a phone, done. If your request suggests otherwise, the problem is the message, not their resistance. | What they say | What it usually means | What works | | --- | --- | --- | | "Just email it to me" | They do not want to register anywhere | Explaining there is no registration | | "I'm not good with those things" | They fear it is complicated | An example or a two-minute call | | "I already sent it" | They sent it to a person, not to the file | Asking them to reply on the same link | | "I haven't got time" | It is not a priority for them | A concrete date and a clear consequence | > [!IMPORTANT] > The third row is the commonest and looks least like resistance. Receiving documentation in someone's inbox is exactly the problem you are trying to solve: if it ends up there, you have not moved forward even though the supplier cooperated. ## Case 2: the client who imposes their portal There is no negotiation here and it is not worth attempting: if your client requires uploading to their platform, you upload. What is up to you is not doing the work twice. 1. **Your file remains the source** — Prepared, reviewed and kept here; whatever they ask for gets uploaded there. 2. **Record what you uploaded and when** — Their portal is theirs: if it changes or closes tomorrow, your evidence must be yours. 3. **And do not duplicate the review** — Review once, here. Their portal is a destination, not a second archive. > [!WARNING] > The expensive mistake in case 2 is stopping keeping copies "because it's already on their portal". When the relationship ends, that access disappears — and with it two years of your documentation. ## And the middle case **En corto** - A client who accepts any route: send them yours, with your branding. - A partner with their own system: agree who keeps the whole. - And a one-off collaborator: scoped access, nothing to set up. > [!NOTE] > None of this requires the other side to contract or pay. Whoever supplies or signs consumes nothing: consumption always falls on the requester. **Can the request be sent from our domain?** Yes, and it helps a lot with sceptics. **What if the supplier emails the document anyway?** Upload it to the file and thank them; what matters is where it ends up. **Is it worth insisting they use the link?** Yes, for the outcome rather than the principle: the link leaves a record and email does not. ## Ejemplos **A twenty-year supplier refuses to "sign up to yet another platform".** - They explain there is no sign-up and send an example - He uploads from his phone in two minutes → He supplies as always and the documentation ends up in the file, not in an inbox. **A twenty-year supplier refuses to use the link and keeps emailing.** - Uploads their document to the file yourself on receipt - Sends them the link on the channel they do use - Shows them once what they gain: seeing what they are missing without phoning → The file is complete from day one and the supplier changes when they see the benefit, not under pressure. **They are pressed and the relationship suffers.** - Accepts their channel and adapts the record → The file moves without a commercial cost. **The supplier says they have no time to learn another tool.** - Shows them there is nothing to register for → The objection disappears in one sentence. **They email it and nobody uploads it to the file.** - Assigns somebody to upload it on receipt → The delivery is recorded even arriving another way. **They are written off and left with no file.** - Records whatever they send, however it arrives → No supplier falls outside the control. **The contact person changes and the new one does use the link.** - Tries again with every change of contact → The resistance was one person's, not the company's. **Their way is accepted and nobody records why.** - Notes the exception in their file → The team knows why that supplier works differently. --- --- id: KB-CL-013 url: https://app.codecontract.io/help/collaboration/when-two-rules-collide idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-005, KB-CL-010] citadoPor: [KB-CL-015, KB-CL-019] --- # When two rules collide _Automations that contradict each other, loop, or stop making sense together._ **Responde a:** two automations contradict each other · rule firing in a loop · too many automatic alerts · reviewing our active rules Automations get added one at a time and always look reasonable on their own. The problem appears in month six, when there are fifteen and nobody holds in their head how they interact. ## The four symptoms | Symptom | What is usually behind it | | --- | --- | | Someone gets three alerts about the same thing | Two rules cover the same case | | An alert arrives and a minute later the opposite one | One rule undoes what the other does | | Consumption rises with no new activity | Something fires far more than expected | | People have stopped reading alerts | The worst of the four, and the quietest | > [!IMPORTANT] > The fourth symptom is the one to watch. When automatic alerts are ignored as a matter of habit, you do not have a rules problem: you have an alerting system that no longer alerts, and the day an important one arrives it will be ignored too. ## How to untangle it 1. **List the active rules and what triggers each** — Two doing almost the same thing nearly always turn up. 2. **Check how many times each has fired** — The number separates the useful ones from pure noise. 3. **Switch off before tuning** — If a rule has added nothing in three months, remove it. Tuning it prolongs the problem. 4. **And keep one rule per situation** — Two rules for the same case always end up disagreeing. > [!WARNING] > Beware rules that trigger on another rule's result. That is where loops come from: the first marks something, the second reacts to the mark, and that re-triggers the first. If two rules watch each other, one of them should be manual. ## How to avoid getting there **En corto** - Add one at a time and wait a month before the next. - Write in one line what problem each solves. - And review the set twice a year, not when it already hurts. That second line helps most at review time: a rule whose purpose nobody can explain is exactly the one to remove. > [!NOTE] > Every firing consumes like a manual action. A looping rule does not only create noise: it creates spend, and it is usually discovered through the invoice before the complaints. **Can they be switched off temporarily?** Yes, and that is sensible while diagnosing. **How do I know which rule did what?** The activity log shows it, including the responsible rule. **How many rules are too many?** When you can no longer explain from memory what each does. ## Ejemplos **A team stops reading alerts because they arrive duplicated and contradictory.** - Lists active rules and switches off those that added nothing in three months - Keeps one rule per situation → Alerts get read again because they mean something again. **Two rules fire on the same event and the supplier gets two different notices the same day.** - Checks which rules are active on that event - Decides which one prevails and disables or narrows the other - Verifies with a real case before treating it as solved → The supplier receives a coherent message and the system stops contradicting itself. **One rule closes the file and another reopens it.** - Orders the conditions so they do not overlap → The file has one status, not two. **Nobody knows which rule won in a specific case.** - Checks the run history → The behaviour is explicable. **A rule is added without looking at the existing ones.** - Reviews the existing ones before creating a new one → The system does not accumulate contradictions. **Two departments create rules for the same process.** - Centralises who can create rules → Rules answer to shared criteria. **One is disabled and something needed stops happening.** - Notes what it did before disabling it → The gap is visible rather than discovered. **The overlap only surfaces when a supplier complains.** - Reviews the rule set periodically → The conflict is caught before it reaches outside. --- --- id: KB-CL-014 url: https://app.codecontract.io/help/collaboration/letting-the-client-see-how-their-work-is-going idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-001, KB-CS-035] citadoPor: [KB-CL-016] --- # Letting the client see how their work is going _Giving visibility cuts calls, but you must decide beforehand what is shown and what is not._ **Responde a:** let the client check their case status · giving client access without oversharing · reducing follow-up calls · client portal for documentation A considerable share of any service company's time goes on answering "how is mine going?". The answer exists, it is up to date, and the person asking cannot see it. Showing it costs little and removes those calls — provided you decide beforehand what is included and what is not. ## The three levels, from least to most | Level | What the client sees | When it fits | | --- | --- | --- | | Their specific document | Only what they sign or supply, via their link | Always; nothing to administer | | The status of their matter | What is missing, what was delivered and when | Long relationships: sites, cases, services | | Access to their file | The documents, with read permission | When the client asks and there is trust | > [!IMPORTANT] > Level one covers most cases and almost nobody exploits it. A third party can view, supply and sign their own by following their link, with no account, no password and no user for you to manage. Anything resolved there is visibility that costs nothing in administration. ## What to decide before opening it 1. **What they will NOT see** — Your costs, your internal notes and what others supplied. Write it down before opening, not after. 2. **What each status means** — "Pending" must mean the same to you and to them, or you will create more calls than you remove. 3. **Who answers what they ask when they see something** — Visibility creates new questions at first; they need a recipient. 4. **And until when** — When the work ends, access is withdrawn or left; both are valid, but decide. > [!WARNING] > Beware showing status without showing who it depends on. If the client sees "pending" and cannot see that the pending item is theirs to supply, visibility turns against you: it will look as though you are the ones not moving. Status must always say whose turn it is. ## What usually happens when you open it **En corto** - Follow-up calls fall, but not in month one: in the first month they rise. - Questions appear about things nobody looked at before, and nearly all are reasonable. - And the client starts supplying earlier, because they can see the gap. That third effect is what pays for the rest: when someone sees what is missing on their side, they send it without being asked three times. > [!NOTE] > Everything the client does from their access is recorded like yours: when they looked, what they supplied and when. It is useful precisely in relationships where who delayed what gets argued later. **Do they have to register?** For their own, no: they enter by their link. For the full file, you grant access. **Can they see what others supplied?** Only if you decide so; not by default. **What if the client has several contacts?** One access each: that way the record says who saw what. ## Ejemplos **An advisory firm gets weekly calls from clients asking what is missing.** - Opens each case's status showing whose turn each item is → Calls fall after the first month and clients supply without being chased. **A client phones weekly to ask how their file is going and takes half an hour of the team's time.** - Gives them read access to their own file - Limits the scope to what is theirs and what they should see - Lets them see the status without being able to change anything → The weekly calls disappear and the client sees progress without anyone stopping to explain it. **The client sees internal documentation that was not theirs.** - Checks the scope before granting access → They see theirs and nothing more. **They get access and then ask about things they do not understand.** - Explains once what each status means → The autonomy is real from the start. **The project ends and their access stays active.** - Sets an expiry date when granting it → Access closes with the work. **The client sees a half-finished status and takes alarm.** - Shows only the statuses that mean something to them → Transparency does not create noise. **Several people from the client ask for access.** - Records them as participants with their scope → Each enters in their own name. **Nobody knows what the client has consulted.** - Checks the access log → Transparency runs both ways. --- --- id: KB-CL-015 url: https://app.codecontract.io/help/collaboration/an-automation-got-it-wrong-with-a-third-party idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-013, KB-CO-008] citadoPor: [KB-CL-019] --- # An automation got it wrong with a third party _A notice went out that should not have, and a client has already seen it. What to do, in order._ **Responde a:** a reminder was sent by mistake · an automatic rule notified the wrong person · cancel a send that already went out · apologising for a wrong automated notice Sooner or later it happens: a rule fires on data that was not what you thought, and a reminder goes out to a supplier who had already delivered, or an expiry warning for something already renewed. The bad news is you cannot unsend. The good news is it is usually fixed in an afternoon if done in the right order. ## The order that works 1. **Switch the rule off first** — If it stays on, it is sending more while you write the apology. It is the most skipped step. 2. **Check how many people received it** — It changes the response entirely: one contact is not two hundred. 3. **Tell them before they ask** — One line, no technical excuses: what arrived, why it did not apply, and what to ignore. 4. **And fix the cause, not the case** — Correcting that one file and leaving the rule alone guarantees a repeat next month. > [!IMPORTANT] > The third step decides how the third party experiences it, and it is worth doing even when the error is harmless. A client who gets an odd notice and hears nothing more concludes your system sends things at random; the same client told within twenty minutes concludes you are on top of it. Same error, opposite readings. ## What NOT to do | Not this | Why | | --- | --- | | Send another automated correction | If the first went wrong, the second arrives under the same suspicion | | Explain the technical detail | The recipient does not care which rule it was; they care whether they must act | | Wait and see if anyone complains | Those who do not complain read it too | | Delete the trace of what went out | It is the only thing that lets you explain later what happened | > [!WARNING] > The nuance that surprises people looking at the breakdown: the correction **is also a send**, and counts as an action just like the mistaken one. If the wrong notice went to two hundred contacts, the apology is one more send, not two hundred — but the original error was already counted. Not a reason to skip correcting; very much a reason not to leave a misaimed rule running for days. ## How to stop it recurring **En corto** - Every new rule is tested on one or two cases first, not on the whole list. - Rules that write to third parties should ask for confirmation at the start. - And check how often it fired in the first week, which is when surprises show. > [!NOTE] > If the wrong notice had consequences — saying something had expired when it had not, or asking for documents already supplied — note it in that third party's file. If someone reconstructs the relationship weeks later, that note explains a message that would otherwise look like carelessness on your side. **Can a send already out be cancelled?** A signature request can be voided so the link stops working; an email already delivered cannot. **Do I tell everyone or only those who reply?** Everyone who received it: the others read it too. **What if the agent did it rather than a rule?** Same order. And review how far you had let it act. ## Ejemplos **A rule sends expiry reminders to thirty suppliers who had already renewed.** - Switches the rule off, checks the reach and tells all thirty the same day - Fixes the rule's condition, not just the files → No supplier calls to ask, and the error does not repeat the following month. **A rule sends a reminder to a supplier who had already delivered, and they phone annoyed.** - Checks which rule fired it and on what condition - Narrows the condition so it checks the status first - Writes to the supplier explaining the error → The error is fixed in the rule and does not repeat with the other hundred and twenty suppliers. **The automation sends a notice containing another supplier's data.** - Stops the rule and checks the scope → The error is cut before it repeats. **The error is discovered a week later.** - Reviews the run history periodically → The fault is caught in hours. **Nobody knows how many received the wrong notice.** - Checks that rule's send log → Those affected are warned rather than everyone. **The rule is fixed and whoever received it is not told.** - Writes to those affected explaining what happened → The relationship does not suffer from silence. **The whole rule is switched off over one case.** - Narrows the condition instead of switching it off → What worked keeps working. **The error repeats because nobody documented it.** - Notes what happened and what changed → The next person does not reintroduce it. --- --- id: KB-CL-016 url: https://app.codecontract.io/help/collaboration/when-the-other-party-is-a-person-not-a-company idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-012, KB-CC-012, KB-CL-014, KB-CL-018] citadoPor: [KB-CC-017] --- # When the other party is a person, not a company _An employee, a tenant, a patient or a private customer does not behave like a supplier, and should not be treated like one._ **Responde a:** requesting documents from a private individual · signing with consumers · the employee will not sign what i send · tenant or patient documentation Almost everything that works with suppliers can be applied to individuals, but four differences change the outcome. Ignoring them explains most cases where a process that ran beautifully with companies stalls with private individuals. ## The four differences | With a company | With a person | | --- | --- | | Someone's job is to answer you | Answering you is nobody's job | | Email is read during working hours | The phone is checked at any hour, email almost never | | They know what the documents are and where | They may not know exactly what you are asking for | | The data belongs to the company | The data is theirs, and that changes your obligations | > [!IMPORTANT] > The fourth carries the most consequences and gets the least thought. When the other party is a person, what they supply is **their** personal data: ask only for what is needed, say what for, and do not keep it longer than necessary. Over-asking "just in case" is awkward with a company; with a person it is a decision you answer for. ## What changes in practice 1. **The channel** — A phone message works far better than email, and is often the only one read. 2. **The wording** — Document names they recognise: "your ID, both sides", not "identifying documentation". 3. **The effort expectation** — If they must register or install something, half give up. By their link, with no account, they do not. 4. **And the tone of chasing** — Two spaced reminders, not five: with individuals, over-chasing burns the relationship rather than speeding it up. > [!WARNING] > The commonest mistake is reusing the supplier template with four words changed. Text that looks normal to an accountancy firm — "you are required to submit the requisite documentation within the stated period" — reads to an individual as bureaucracy or outright fraud, and they do not reply. And when they do not, the conclusion is usually that they "are not cooperating", when the problem was the message. ## What should stay the same **En corto** - That what they supply enters the file, not someone's personal inbox. - That there is a record of what was asked, when, and what arrived. - And that signing happens through a route that leaves evidence, not an "ok" by message. That last one protects both sides: in a relationship with an individual, proof of what they accepted and when is as useful to them as to you. > [!NOTE] > If you will handle documentation for many people — staff, tenants, patients, students — decide beforehand what is kept and for how long. It is the part that cannot be fixed afterwards and the one that weighs most if someone exercises their rights. **Can I remind them on WhatsApp?** If you have a basis to use that channel with that person, yes, and it usually works much better. **What if they send the photo by messaging?** Upload it to the file: what cannot happen is it living only on someone's phone. **Do they need to create an account?** No, and that is exactly what to avoid: they enter by their link and supply or sign. ## Ejemplos **A letting agency uses its supplier template with tenants and nobody replies.** - Rewrites the request with document names people recognise - Sends by phone and leaves two spaced reminders → Tenant documentation arrives in days instead of weeks, with no phone calls. **Documentation is requested from a sole trader in the same tone and volume as from a hundred-person company.** - Requests the minimum that meets the requirement - Explains in one line what each item is for - Gives them somewhere to upload without registering → The sole trader delivers the same day instead of giving up for not knowing where to start. **They are sent a portal with registration and never get in.** - Sends the direct link with no account → They deliver without friction. **Nine documents are requested at once.** - Requests two and adds the rest later → The first attempt completes. **They are written to in large-company jargon.** - Writes as you would speak to them on the phone → The message is understood without a call. **Reminders arrive daily and they feel hounded.** - Spaces out the cadence → The relationship does not suffer. **They send a photo of the document from their phone.** - Accepts the photo if it reads and records it → The delivery counts and the file moves on. **A document that does not exist in their case is requested.** - Checks what applies to a sole trader before asking → The impossible is not chased. --- --- id: KB-CL-017 url: https://app.codecontract.io/help/collaboration/two-people-working-on-the-same-file idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TD-014, KB-TD-006] citadoPor: [KB-CL-018] --- # Two people working on the same file _When two colleagues chase the same supplier, the supplier looks bad and you lose the time._ **Responde a:** two people request the same thing from a supplier · colleagues duplicating work · who owns this file · avoiding duplicate requests in the team It happens in any team of more than two: two colleagues work the same matter without knowing, and the third party — the supplier, the client — gets two similar requests, answers one, and is left with the impression that you do not talk to each other in there. ## How it shows up | Symptom | What is happening | | --- | --- | | The supplier says "I already sent it to your colleague" | Two requests, one answer, and the other still open | | Two reminders arrive about the same thing | Nobody closed the request on receipt | | Two people approve the same thing differently | It was not clear who decided | | Someone redoes work already done | The result existed, but somewhere else | > [!IMPORTANT] > The first row is the commonest and has an invisible consequence: **the supplier is right and you are still waiting**. They sent what was asked, to whoever asked; what failed is that the delivery did not close the other request. And when you chase, the relationship suffers over something they did not do wrong. ## What prevents it, and it is not a meeting 1. **One owner per file, by name** — Others help, one answers. Without that, everything else is a patch. 2. **Request from the file, not from email** — It is what makes visible that a request is already open on that. 3. **Close the request on receipt, not at day's end** — An open request with the document already in is what fires the second reminder. 4. **And look at the file before writing** — Ten seconds that prevent the whole conversation. > [!WARNING] > What annoys the third party most is not receiving two requests: it is receiving the second **after having answered the first**. To them it means you did not read them. If you spot that it happened, say so before they do — one line acknowledging it costs less than the distrust it otherwise leaves. ## When two people must work at once **En corto** - Split by parts of the file, not by shifts: one handles documentation, the other the technical side. - Have communications always go out from the same place, whoever writes them. - And make clear who decides if something must be decided. The second solves nearly everything: if the third party always hears from the same sender and replies to the same place, how many of you are behind it does not matter to them. > [!NOTE] > The log says who requested what and when, so these situations are clarified by looking rather than reconstructing from memory. What it does not fix is the impression the third party took away, which is why heading them off early matters. **What if two of us handle it deliberately?** Then one is the owner and the other supports: two owners is none. **Do two requests count as two actions?** Yes: every send counts, even the same document to the same person. **Can I see whether a request is already open?** Yes, in the file itself: that is exactly what prevents the duplicate. ## Ejemplos **A supplier receives two requests for the same certificate in one week.** - They assign an owner per file and close requests on receipt → Crossed reminders stop and the supplier stops replying "I already sent it". **Two people work the same file and both write to the supplier on the same Tuesday.** - Assigns an owner to the file - Checks who handles it before writing - Leaves notes in the file rather than in each inbox → The supplier receives one message and the team does not duplicate work. **One approves a document and the other rejects it the same day.** - Writes the criteria into the template → The decision is the same whoever takes it. **Each keeps their notes in their own inbox.** - Records notes in the file → The context is shared. **One goes on holiday and the other does not know where things stood.** - Checks the file's history → The handover does not depend on a conversation. **Both chase the supplier with different deadlines.** - Sets the deadline in the file itself → The supplier receives one date. **Nobody knows who did what in the file.** - Checks the log with author and date → Every action has an owner. **The file moves on and the other finds out late.** - Sets change notifications for both → Both work on the same thing. --- --- id: KB-CL-018 url: https://app.codecontract.io/help/collaboration/when-your-supplier-subcontracts-someone-else idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-011, KB-CL-008, KB-CL-017] citadoPor: [KB-CL-016] --- # When your supplier subcontracts someone else _Documents start arriving in the name of a company that is not in your contract. What to do with them._ **Responde a:** my supplier has subcontracted another company · a certificate arrives from a company I do not know · who answers if the subcontractor fails · supply chain documentation You hired one company and suddenly the delivery note comes from another, the technician who turns up wears a different logo, or the certificate arrives in a third party's name. It is neither rare nor necessarily a problem — it becomes one when it happens with nobody saying so and the documents come in anyway. ## What changes and what does not | Aspect | What happens when there is a subcontractor | | --- | --- | | Who answers to you | The company you hired, unless you agreed otherwise | | Who produces the documents | It may be the other one, and usually is | | Who you claim against | Your supplier, not whoever carried out the work | | What you must be able to show | That you knew who was working and with what documentation | > [!IMPORTANT] > The fourth row is the neglected one and the one anyone reviewing asks about: **a document in the name of a company that does not appear in your contract says nothing on its own**. With no record that this third party was authorised by your supplier to do that work, you hold a certificate that cannot be tied to anything. And it cannot be fixed later, because what is missing is the link between the two, not the paper. ## How to tie it down without slowing the work 1. **Ask them to notify the subcontracting** — An email from the supplier saying who they delegate to and for what is enough. 2. **Keep that email in the same file** — It is the piece that links the document to your contract. 3. **Ask the subcontractor for what you ask the supplier** — Through the same process: no need to invent a new one. 4. **And note the date from which they are involved** — If something happened before or after, that date settles it by itself. > [!WARNING] > The most surprising part of this situation: **whoever has to ask the subcontractor for documents is usually your supplier, not you** — it is their relationship, not yours. Yet whoever answers for not having them, when someone reviews, is still you. That asymmetry is uncomfortable and it is real, and it is handled by asking your supplier: let them hand the documents over, even if someone else produced them. ## When it is worth stopping **En corto** - When there are more links than you were told and nobody knows how many. - When the subcontractor changes weekly and no documentation arrives for any of them. - And when the work needs a specific authorisation: there, nobody is accepted unchecked. > [!NOTE] > How far you are required to control the chain depends on the sector and the type of work, and some have specific subcontracting rules. **Your adviser settles that**; what matters here is that traceability of who did what is lost at the first link nobody wrote down. **Can I forbid subcontracting?** That is a contract clause, and your adviser will tell you how to word it. **What if I find out by chance?** That is the signal to ask for it in writing, not that there is bad intent. **Do I give the subcontractor access?** Better that they contribute the same way any third party does, with their own trace. ## Ejemplos **A company receives certificates in the name of a firm that is not in its contract.** - Asks its supplier for the email authorising the subcontractor and files it alongside → The certificate is linked to the contract, and the review no longer has a loose end. **Your maintenance supplier sends a different company and nobody knew until the van arrived.** - Agrees contractually whether they may subcontract and on what terms - Records which firms are authorised for each supplier - Requires of the subcontractor what is required of the supplier → The chain is known before the job and the documentary gap does not sit on your balance sheet. **The client asks about the subcontractor and nobody knows who they are.** - Asks the supplier to declare their chain → The answer exists before the question. **The subcontractor does not meet what the supplier signed.** - Passes the same list down the chain → The commitment reaches whoever executes. **Subcontracting is authorised verbally.** - Records it with its scope and date → What was authorised is demonstrable. **The subcontractor changes and nobody communicates it.** - Asks to be informed of any change → The change arrives before the job. **A review asks who was on the premises on a specific day.** - Checks the record of authorised access → You answer using that day's date. **The subcontracting is discovered during an audit.** - Reviews the declared chain periodically → The finding is made before the auditor makes it. --- --- id: KB-CL-019 url: https://app.codecontract.io/help/collaboration/when-to-switch-an-automation-off idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-013, KB-CL-010, KB-CL-015] citadoPor: [KB-CL-002] --- # When to switch an automation off _Plenty is said about which ones to switch on. Spotting which one is doing harm matters as much and nobody says it._ **Responde a:** an automatic rule hurts more than it helps · disabling an automation · the team works around the rule · too many automatic notices Automations are built with a clear purpose and stay forever, even after the work they described has changed. Nobody reviews them because they do not annoy enough to deserve an afternoon — only enough for people to learn to dodge them. ## The signs that one is surplus | Sign | What it really means | | --- | --- | | The team has invented a trick to dodge it | The rule no longer describes how you work | | Exceptions outnumber the normal case | The rule is written backwards | | Nobody remembers who built it or why | Nobody will be able to judge whether it still makes sense | | Its notice is filed unread | It no longer informs: it is noise | | It creates work undoing what it did | It is subtracting, however much it looks like saving | > [!IMPORTANT] > The first row matters most and is looked at least: **when someone finds a way around a rule, the data starts lying without anyone lying**. If, to stop a notice firing, the team leaves a file in a state it should not be in, your reports reflect that workaround rather than reality. The automation has not merely stopped helping: it is distorting what you see. And you will not catch it on the dashboard, because the dashboard is precisely what has turned false. ## How to decide without arguing 1. **Look at how many times it fired last month** — Zero means retire it. Constant means look harder. 2. **Ask whoever suffers it, not whoever built it** — The one who configured it remembers it fondly; the receiver does not. 3. **Disable it for two weeks before deleting** — If nobody misses it, you have your answer. 4. **And note why it was retired** — It stops someone rebuilding it a year from now. > [!WARNING] > And one case deserves separate treatment: **an automation that reaches outsiders is not switched off without telling them**. If your suppliers have spent a year receiving an automatic reminder and it stops, they do not think you turned it off: they think the document is no longer needed. What is retired internally is simply retired; what went outwards is replaced by something or announced. ## What is worth reviewing once a year **En corto** - Which rules are active and who answers for each one today. - Which have never fired: either the case does not occur or they are written wrong. - And which fire every single time: that is no longer an exception, it is your normal process. > [!NOTE] > Switching an automation off is not admitting a mistake: what worked at twenty files a month can get in the way at two hundred. It would be odd if all of them still fitted two years on. **Can it be disabled without deleting?** Yes, and that is the way: if it turns out to be needed, switch it back on. **What if it only annoys one person?** Check whether that person is the heaviest user. Usually they are. **How many should we have?** As many as someone can explain. If nobody knows what one does, it is surplus. ## Ejemplos **A team parks files in the wrong status to stop an automatic notice firing.** - Disables the rule for two weeks and checks whether anyone misses it → Nobody misses it, and the statuses go back to saying what is actually happening. **An automation has run for eight months and nobody knows whether it is still needed.** - Checks how many times it fired last quarter - Checks whether the process that justified it is unchanged - Switches it off if it adds nothing, noting what it did → The system does what the company needs today, not what it needed a year ago. **The automation annoys more than it helps.** - Asks whoever receives it → The decision is taken with whoever bears it. **It is switched off and something needed stops happening.** - Notes what it did before switching it off → The gap is visible rather than discovered. **It is switched off and nobody picks up what it did.** - Assigns somebody what it was doing → Switching off leaves no orphaned work. **It is kept just in case, without knowing whether it works.** - Checks the run history → What works is what gets kept. **Nobody knows who may switch it off.** - Records an owner for each rule → The decision has an owner. **It is switched off unannounced and somebody misses it.** - Communicates the change before applying it → Nobody discovers the change through a failure. --- --- id: KB-CL-020 url: https://app.codecontract.io/help/collaboration/two-clients-that-compete-with-each-other idioma: en categoria: colaboracion subcategoria: externos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-011, KB-CL-001] citadoPor: [KB-CL-012] --- # Two clients that compete with each other _You work for both and neither wants the other to know a thing. The separation is not about folders: it is about people and names._ **Responde a:** working for two competing companies · keeping client information separate · conflict of interest between clients · stopping one client seeing another It happens to any law firm, consultancy, engineering practice or specialist supplier: two clients in the same sector, sometimes direct competitors, both telling you things they would not say in front of the other. It works until someone slips, and the slips are almost never about documents. ## Where it leaks in practice | Route | How it happens | What prevents it | | --- | --- | --- | | Names | A list, a template or a link mentioning the other | Each seeing only their own, titles included | | People | Someone on the team works on both | Deciding who goes where, and writing it down | | Conversations | An example offered in good faith in a meeting | The rule is never to illustrate with the other | | Reused documents | A template retaining data from the original | Starting from a clean base, not from earlier work | > [!IMPORTANT] > The first row surprises people and is the most neglected: **they do not need to see the other's document; seeing their name is enough**. A dropdown listing clients, a file title, an attachment keeping its original filename. No confidential data has leaked, and yet the client now knows you work for their competitor — and from that moment the conversation is a different one. Separation starts with what is visible, not with what is stored. ## How the separation is built 1. **One space per client, not a folder inside the same one** — Whatever sits in the same place eventually gets seen. 2. **Access by person and by client, reviewed** — Teams change and access is inherited unnoticed. 3. **Your own templates, not copies of the other's work** — A reused document carries more than shows. 4. **And a conversation rule, said out loud** — It is what prevents the well-meant example in a meeting. > [!WARNING] > On the team: **someone who has worked for both cannot un-know what they know**, and permissions no longer cover that. If a person moves from one client to the other, decide it explicitly and, depending on the sector, tell the parties. It is uncomfortable and it protects exactly what is at stake — because the day one of them finds out on their own, the question will not be whether there was a leak, but why you did not say so. ## When it must be disclosed and when it cannot be accepted **En corto** - If the engagement is about the other client, no separation will do. - If one contract bars you from working for the other, it is a legal question, not an organisational one. - And if you are unsure whether to disclose, that doubt is already the answer to check. > [!NOTE] > Which confidentiality and conflict-of-interest duties apply depends on your profession, your contracts and your professional body or sector. **Your adviser settles that**; here we describe how to avoid the accidental leak, which is the one that actually happens. **Are separate folders enough?** No: they separate content, not names or people. **Can I use an anonymised piece of work as an example?** Carefully: in small sectors the case is recognised without the name. **What if one of them asks me directly?** Answer truthfully within what you may say, and check first what that is. ## Ejemplos **A consultancy sends a client a template still carrying another client's original filename.** - Starts from a clean base and reviews who sees which names, not only which documents → The client does not learn from a filename that they also work for the competition. **Two competing clients ask for access to files on the same shared project.** - Separates each one's scope before granting anything - Checks what each would see of the other - Records what was shared with whom → Each client sees their own and there is no way for one to infer the other's. **A report mentioning the competitor is shared.** - Reviews the content before sharing → Nothing is leaked that should not be. **One employee handles both clients and mixes contexts.** - Separates the files and limits cross access → The error stops being possible by oversight. **Both appear on the same recipient list.** - Checks the recipients before sending → Nobody sees who else you work with. **A client asks whether you work with their competitor.** - Answers within what the contract allows → The answer is given on a basis rather than improvised. **The same template is reused and the other's name appears.** - Reviews templates before reusing them → The document goes out clean. **Nobody knows what each has seen.** - Checks the access log → The separation is demonstrable. --- --- id: KB-CL-005 url: https://app.codecontract.io/help/collaboration/rules-that-create-tasks-by-themselves idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-002, KB-TD-003] citadoPor: [KB-CL-010, KB-CL-013] --- # Rules that act on their own _"When this happens, do that": automating without any coding._ **Responde a:** automate actions when something happens · create automatic tasks · automatic workflow rules · get warned automatically when a document is missing A lot of repetitive work has the shape "when X happens, do Y": when the case completes, tell production; when insurance expires, open a task; when a document is missing, remind someone. That can be written down once. ## The shape of a rule | When this happens… | …do this | | --- | --- | | A case completes | Notify whoever has to act | | Something mandatory expires | Create a task with an owner | | A document is rejected | Notify whoever requested it | | A missing document is detected | Open the reminder to the third party | | It has been stuck X days | Create a task to phone them | > [!IMPORTANT] > A rule turns an intention into something that happens. That is also its risk: a badly set rule does its thing hundreds of times with nobody stopping it. Start with one, watch it for two weeks, then add the next. ## What is worth automating **En corto** - What is always done the same way and involves no decision. - What gets forgotten for being dull, not for being hard. - What triggers work for someone else on the team. ## What is not Anything with an "it depends". Approving, rejecting, blocking a supplier or accepting a document are decisions, and a rule does not answer for them if it goes wrong. > [!WARNING] > Every action a rule triggers consumes, exactly as if a person did it. A rule firing a thousand times spends a thousand: check the breakdown in the first month. > [!NOTE] > The rule that gives back most is nearly always the dullest: open a task when something has been stuck too long. It is what nobody does by hand and what prevents the most dead cases. **Can I stop them?** Yes, and it is worth knowing how before you need to. **Is what a rule did recorded?** Yes, the same as a person's actions. **How many should I have?** Few and understood. Twenty rules nobody remembers is a system nobody controls. ## Ejemplos **A company accumulates stalled cases because nobody reviews which have not moved in weeks.** - Sets one rule: at 21 days stalled, open a task for the owner → Dead cases stop piling up without anyone having to remember to review them. **A rule launches onboarding when a supplier is created and nobody reviews what it triggers.** - Checks which rules are active and what each does - Tests the rule on a real case before letting it run - Reviews at four weeks whether it still makes sense → The system does known things rather than surprising somebody on a Tuesday. **Two rules fire on the same thing and the supplier gets two notices.** - Checks for overlap before adding a new one → The recipient receives one message, not two. **A rule fires on a case nobody anticipated.** - Narrows the condition as much as possible → The rule acts where it should. **The rule is a year old and the process changed six months ago.** - Reviews rules when the circuit changes → The system keeps up with the process. **A rule is switched off and nobody knows what stopped happening.** - Notes what it did before switching it off → The gap is visible rather than discovered. **Nobody knows who created a rule or why.** - Records the reason when creating it → The rule can be reviewed on a basis. **A rule sends emails in the middle of the night.** - Configures the sending window → The notice arrives when somebody can act. --- --- id: KB-CL-006 url: https://app.codecontract.io/help/collaboration/an-agent-that-fetches-the-document idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-004, KB-CL-002] citadoPor: [KB-CL-007] enLaApp: https://app.codecontract.io/agents --- # An agent that goes and fetches the document _When the document is not held by a person but by a portal you have to log into._ **Responde a:** automatically download documents from a government portal · agent that logs into a portal to fetch a certificate · automate certificate downloads · ai agent that browses websites Not all the documentation you are missing is held by a person. Much of it sits in a portal — a government site, a customer's web area, an insurer's private area — and someone on your team has to log in, find it and download it. That can be delegated too. ## The three things it can do | Task | What it does | Example | | --- | --- | --- | | Fetch | Logs in, locates the document or data and brings it back | Downloading a certificate from a government portal | | Deliver | Logs in, uploads or fills in what you give it and confirms | Submitting documentation on a customer's portal | | Review | Looks at what is there and proposes approving or rejecting with a reason | Checking a certificate meets what was required | ## Where it always stops At a CAPTCHA. The agent does not solve it and does not try: it reports that a person is needed and waits. The same goes for any step requiring a decision you have not delegated to it. > [!IMPORTANT] > That it **can review and propose** approving or rejecting does not mean it should decide alone. Approving a document has consequences that remain yours: leave it proposing and have a person confirm, at least until you have spent weeks seeing it get things right. ## Before you delegate anything: the awkward conversation Logging into a portal requires credentials, and in some cases your company's digital certificate. That is not a configuration detail: it is granting access to an official portal in your name. **En corto** - Decide expressly which portals yes and which no. - Start with the lowest-consequence ones, not the tax authority. - Read the full log of the first runs, not a glance. > [!WARNING] > Also check that doing it this way is permitted by that portal's terms of use. Some official sites and private areas expressly prohibit automated access, and the platform cannot know that for you — ask your adviser before automating a specific one. ## What gets recorded Everything: what it did, in what order, what it found and where it stopped. Each run leaves a full log, and that is what lets you understand what happened when something does not go as expected. > [!NOTE] > A job consumes several times over: running it, logging the activity and storing the result each count separately. It consumes more than asking a person for the document, and pays off when that person is you logging into the portal every month. **What if the portal changes its layout?** It may fail, and it will say so. It does not invent a result it could not obtain. **Can I see what it did?** Yes, the full log of each run. **Does it work on any website?** On those navigable like a person would. With a CAPTCHA or two-factor, a person will be needed. ## Ejemplos **A firm downloads the same certificate from a portal for 40 clients every month.** - Delegates fetching to an agent - Reads the full log of the first runs - Keeps a person confirming before accepting the result → The 40 downloads stop taking a morning, and when the portal changes the agent reports it instead of bringing back the wrong thing. **A supplier document is missing and somebody spends twenty minutes writing to them and hunting for it.** - Lets the agent identify what is missing and who to ask - Reviews the message before it goes out - Checks afterwards what it obtained and what it did not → Twenty minutes become two of review, and the supplier receives a correct request. **The agent asks for something already delivered.** - Checks it consults the status before asking → Nobody receives a request for what they already sent. **The agent writes in a tone that is not yours.** - Reviews and adjusts the template it uses → The message sounds like your company. **The agent chases daily and the supplier stops reading.** - Configures the cadence → The nudge works again. **The agent fails to obtain the document and nobody knows.** - Checks which attempts came back empty → The case moves to a person when it should. **The agent contacts somebody who has left the company.** - Checks it uses the current contact → The request reaches somebody who can act. **It is asked to obtain something that does not exist.** - Checks first whether the document can exist → The impossible is not chased. --- --- id: KB-CL-007 url: https://app.codecontract.io/help/collaboration/how-far-to-delegate-to-an-agent idioma: en categoria: colaboracion subcategoria: automatico audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CL-006, KB-CL-004] citadoPor: [KB-MA-013] --- # How far to delegate to an agent _The line between saving work and shifting a risk that stays yours._ **Responde a:** can i let ai approve documents · how far to automate with agents · who is responsible if the agent gets it wrong · supervising an ai agent An agent can do almost anything a person with a browser can. The useful question is not what it can do but what it should — and the answer turns on one thing: who answers if it goes wrong. ## The line | Kind of task | Delegate? | Why | | --- | --- | --- | | Log into a portal and download a document | Yes | Mechanical and verifiable: either it brings the document or not | | Fill in and submit a familiar form | Yes, reviewing at first | The result can be checked | | Check whether a certificate meets a criterion | Have it propose | It is a judgement, however mechanical it looks | | Approve a supplier | No | It has consequences and you answer for them | | Decide to block someone | No | It affects a third party who did not choose this | > [!IMPORTANT] > If an agent approves a supplier who did not comply and that ends at an inspection, the answer "the system approved it" does not exist. You answer exactly as if someone on your team had approved it, because you were the ones who let it decide. ## How to release it, in practice 1. **Everything reviewed** — For the first weeks, a person confirms every result. That is where you see whether it is right and where it fails. 2. **Release the mechanical** — Downloading, uploading, filling in the usual. If it fails, you notice quickly. 3. **What judges stays proposing** — Permanently, not as a temporary phase. > [!WARNING] > Watch the point where the log stops being read. An agent running well for six months is exactly when nobody checks, and also when a change in the target portal can go unnoticed for weeks. ## What delegating does not change **En corto** - Responsibility for what is approved stays yours. - Duties towards third parties are not delegated with the task. - What the agent did is recorded in your name. > [!NOTE] > The healthy way to see it: an agent is someone new on the team being taught a task. You would not hand over every key on day one, and you would not let them sign decisions you answer for. **Can I undo what it did?** It depends on the action. What was submitted on an external portal, usually not. **What if the portal asks it something it does not know?** It stops and reports. It does not improvise. **Is it worth it for few tasks?** Rarely. It pays off on the repetitive, where time accumulates. ## Ejemplos **A company lets an agent approve supplier clearances to move faster.** - Reverses it: the agent proposes and a person confirms - Releases only fetching and submitting → Keeps the genuine time saving and returns the decision to whoever answers for it. **Full supplier onboarding is delegated to an agent and a week later files are approved unreviewed.** - Delegates first what touches nobody outside - Keeps approval behind human confirmation - Widens only after reviewing what it did in the first week → Delegation grows on verified behaviour rather than on an expectation. **The agent decides something that required business judgement.** - Keeps those decisions out of its scope → Responsibility stays where it should. **It is delegated and nobody ever reviews what it does.** - Reviews a sample periodically → Trust rests on checks. **The agent acts out of hours and nobody expects it.** - Configures when it may act → Its actions happen when somebody is around. **Its scope is widened without telling the team.** - Communicates scope changes → Nobody is surprised by what they no longer do by hand. **The agent and a person do the same thing at once.** - Splits who does what → The supplier does not receive two requests. **The agent is switched off and the work piles up unowned.** - Assigns somebody what it was doing → Switching off leaves no gap. --- --- id: KB-NO-001 url: https://app.codecontract.io/help/regulation/what-is-the-digital-product-passport idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-TZ-002] citadoPor: [KB-NO-002, KB-NO-004, KB-CS-021, KB-NO-006, KB-NO-007, KB-NO-011] --- # What the digital product passport is _What information it asks for, where it comes from, and why it resembles a case file._ **Responde a:** what is the digital product passport · dpp meaning · product passport ecodesign · what information does the dpp carry The digital product passport is a set of information about a specific product — what it is made of, where it comes from, how it is repaired, how it is recycled — usually accessible by scanning a code on the product or its packaging. ## Why it resembles what you already do Because it is the same thing under another name: information coming from third parties — your suppliers — that has to be gathered, that expires, and that someone outside will consult. The difference is who consults it: here it may be a customer, a recycler or an authority. | What you already do | What the passport asks for | | --- | --- | | Request certificates from a supplier | Request composition and origin of each component | | Mark what expires | Keep the information current while the product exists | | Show a case file to an auditor | Let anyone consult it by scanning | ## Where the information comes from **En corto** - From your suppliers, for the most part. - From your own manufacturing processes. - And it has to be updatable: it is not a fixed snapshot. > [!IMPORTANT] > The rollout is being staged by product category and is not the same for everyone. When it affects you and which exact fields you will be asked for is something to confirm with your adviser or trade association: this explains how to have the information ready, not what the rule requires in your case. > [!WARNING] > The hard part is not publishing the passport: it is getting the data from your supplier's supplier. Starting to ask for composition and origin before it is mandatory is what separates arriving early from arriving in a rush. > [!NOTE] > If you sell to large customers, they will probably ask before any authority does. That is usually the first real warning. **Does this replace labelling?** No. It is additional information, accessible digitally. **Do I have to publish it myself?** It depends on your role in the chain; check. **Can I start without knowing the exact date?** Yes, and it is sensible: gathering composition and origin from your suppliers helps under any timetable. ## Ejemplos **A furniture manufacturer is asked by a large customer for per-product composition data.** - Builds a process requesting composition and origin from each supplier - Marks the data that needs renewing → When the formal requirement arrives, they already hold what others are only starting to request. **The information requested is spread across five suppliers.** - Requests each one's part and gathers it into one file → What was scattered becomes consultable at once. **Each supplier sends their data in a different format.** - Requests specific documents to a single destination → What is received is comparable across suppliers. **A figure changes and nobody knows which version was declared.** - Keeps each version with its date → You can say what was declared at each moment. **A supplier's data is missing and they do not reply.** - Records what was requested, when, and what came back → The gap is documented rather than blank. **Preparation for next year starts and nobody knows where to begin.** - Starts by inventorying what information already exists → The real work turns out smaller than it looked. --- --- id: KB-NO-002 url: https://app.codecontract.io/help/regulation/packaging-and-plastics-what-you-must-prove idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-001, KB-NO-003] citadoPor: [KB-NO-001, KB-NO-003, KB-CS-018, KB-CS-026, KB-AL-002, KB-NO-005, KB-NO-009, KB-CS-030, KB-NO-012, KB-IU-012] --- # Packaging and plastics: what you must be able to prove _Composition, recyclability and declarations: data that comes from third parties._ **Responde a:** packaging regulation what documentation · packaging placed on the market declaration · single-use plastics obligations · packaging recyclability certificate Packaging and single-use plastics rules have made mandatory something that used to be commercial: knowing exactly what every package you place on the market is made of, and being able to prove it with paperwork that is not yours. ## Where each item comes from | Data | Who holds it | How to get it | | --- | --- | --- | | Material composition | Your packaging supplier | By asking, and renewing when it changes | | Recycled content percentage | The supplier, with substantiation | Certificate or declaration, dated | | Weight per packaging unit | You or the supplier | Technical data sheet | | Recyclability | The supplier or a test | A document you must keep | > [!IMPORTANT] > The duty to declare usually falls on whoever places the product on the market, even though the supplier holds the data. That means a supplier who does not send the data sheet is not just a purchasing problem: it is your regulatory problem. Confirm with your adviser exactly what you must declare. ## Frameworks cited in this area The European packaging and packaging waste regulation, the single-use plastics directive, extended producer responsibility and collective compliance schemes, plus national waste rules. Timelines and thresholds are being staged and differ by material and by country. > [!WARNING] > Composition data changes when a supplier changes material, and they do not always tell you. Marking those data sheets with an annual expiry is what stops you declaring in 2027 with 2025 data that is no longer true. > [!NOTE] > With dozens of packaging references, this is an annual review per supplier, not a project. What turns it into a project is not having started. **Is a supplier declaration enough or is testing needed?** It depends on the data and the material; check before assuming a declaration suffices. **What about packaging from outside the EU?** Usually where the data is hardest to get, and where it pays to start asking earliest. **How do I prove I asked in time?** The case shows it with send and delivery dates. ## Ejemplos **A packer has 60 packaging references and does not know the recycled content of half of them.** - Launches a request to its 14 packaging suppliers - Marks the data sheets with an annual expiry → Gathers the data in three weeks, and from then on it renews itself yearly. **The composition data sits with the packaging manufacturer.** - Requests it and stores it with the reference → The data lives where it will be looked for. **The supplier changes material and gives no notice.** - Asks them to communicate any change of composition → The change arrives before the client's question. **Recyclability is claimed with nothing behind it.** - Keeps the manufacturer's declaration that backs it → Every claim has its paper. **A client asks for the data on three different references.** - Checks each reference's file → You answer without phoning the supplier. **The packaging documentation expires and nobody notices.** - Records the validity on receipt → The warning arrives before the client does. --- --- id: KB-NO-003 url: https://app.codecontract.io/help/regulation/waste-traceability-and-transfer-documents idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-CS-008, KB-NO-012] citadoPor: [KB-NO-002, KB-CS-020, KB-LG-005, KB-NO-009, KB-IU-011, KB-CN-011, KB-NO-019, KB-NO-020, KB-NO-026] --- # Waste: traceability and transfers _Who took it, where it went, and how to prove it three years later._ **Responde a:** waste transfer documentation · waste chronological register · authorised waste manager documentation · company waste traceability Waste works like subcontractors: responsibility does not end when the lorry leaves your gate. If the manager was not authorised or the waste ended up where it should not, the question comes back to you — and it arrives years later. ## The three blocks you must be able to show | Block | What it covers | Module that helps | | --- | --- | --- | | The manager is authorised | Authorisation valid on the transfer date | Trackline, with expiry marked | | Every transfer is on record | Identification and acceptance documents | Trackline, one case per transfer | | Nothing was altered afterwards | The register, with a trusted date | SmartCheck over the periodic register | > [!IMPORTANT] > The manager's authorisation must be valid **on the transfer date**, not today. That is the classic trap: it gets checked once at contracting and never again, and three years later it turns out it lapsed in between. Marking it with an expiry is what prevents it. ## Frameworks cited Waste and contaminated land regulation, the chronological register, waste transfer identification documents and — for hazardous waste — specific transport requirements. Exactly which documentation applies to you depends on the waste type, your activity and your region; confirm with your adviser. > [!WARNING] > If you produce hazardous waste, the carrier also comes into play alongside the manager, with their own documentation and their own expiry. That is two cases, not one. > [!NOTE] > Certifying the chronological register annually, with its date, turns a record you could have edited into something an inspector cannot argue with. **How long must it be kept?** Periods depend on the waste type and applicable rules; check. **What if the manager's authorisation changes mid-year?** Upload it as a new version; the previous one stays, and it is the one that was valid before. **Does it serve for an environmental inspection?** It is the cross-check they ask for: an authorised manager on that date and a documented transfer. ## Ejemplos **A manufacturer discovers at an inspection that its waste manager's authorisation lapsed for four months.** - Marks the authorisation with an expiry and a 60-day warning - One case per transfer, with its documentation → The history pins down exactly which transfers fell in that window, instead of leaving the whole year in doubt. **Collection receipts pile up in a folder by date.** - Organises them by contractor and waste type → You search the way people ask. **A receipt for a collection a year ago is missing.** - Chases the contractor while the relationship is live → The gap closes while it is easy. **The contractor sends the receipt months later.** - Requests and chases automatically → The document arrives without being hunted. **Nobody knows how much has been removed over the year.** - Checks the history by period → The figure comes from the archive rather than an estimate. **The contractor changes and the history goes with them.** - Keeps its own copy of every receipt → The change does not take the previous years. --- --- id: KB-NO-004 url: https://app.codecontract.io/help/regulation/what-your-large-customers-will-ask-for idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-001, KB-CS-007] citadoPor: [KB-CS-024, KB-CS-025, KB-CS-027, KB-NO-005, KB-IU-003, KB-NO-008, KB-NO-010, KB-NO-013, KB-NO-014, KB-NO-016, KB-NO-017, KB-NO-021] --- # What your large customer will ask for _Regulation reaches you through the supply chain long before the official gazette._ **Responde a:** my customer asks for sustainability data · customer esg questionnaire · supply chain due diligence · they ask for my products carbon footprint The usual way to find out a rule affects you is not reading it: it is a large customer sending you a questionnaire. They are obliged to report on their chain, and their chain is you. ## What they usually ask for, in order of appearance 1. **Data about your company** — Certifications, policies, sometimes consumption. That is the easy part. 2. **Data about your products** — Composition, origin, footprint. Here you already depend on your suppliers. 3. **Data about your suppliers** — Where almost everyone gets stuck, because it has to be requested backwards. > [!IMPORTANT] > The second and third blocks cannot be improvised. A questionnaire arriving with a two-week deadline asking for material origin cannot be answered unless you started asking your suppliers earlier. That is the real reason to start before it becomes mandatory. ## Frameworks behind those questionnaires Corporate sustainability reporting and its standards, value-chain due diligence, the deforestation regulation for certain commodities, and the carbon border adjustment mechanism for certain imported goods. None may apply to you directly and it can still reach you contractually, through someone it does apply to. > [!WARNING] > Answering a questionnaire with estimated figures "to get it off your desk" is the worst possible move: they go on record, with your signature, and they are what gets shown to you when they do not add up. If you do not have a figure, say you do not have it and when you will. > [!NOTE] > A questionnaire answered well gets reused: the next customer asks almost the same things. Keeping the answers with their date and source turns the second one into an afternoon. **Can I refuse to answer?** You can, and sometimes it is the right call. But it is often written into the contract. **What if my suppliers do not answer me?** It is the same problem one link back. The case at least proves you asked, and when. **Does this affect me as a small company?** Contractually, yes. The legal duty may not be yours and the commercial demand arrives anyway. ## Ejemplos **An industrial supplier receives a sustainability questionnaire from its largest customer with a two-week deadline.** - Answers what it has, states what it does not and by when - Launches an origin request to its own suppliers → Keeps the customer without committing to invented figures, and answers the next questionnaire in an afternoon. **The requirement arrives in a contract and nobody reads it fully.** - Reviews what documentation it commits to before signing → You know what the company is committing to. **The client asks for something that depends on one of your suppliers.** - Passes it to the supplier in writing → The chain holds from the outset. **Each client is answered from scratch.** - Keeps its own file current → The second client costs a fraction of the first. **A requirement that cannot be met is accepted.** - Says so before signing and proposes a timeline → The commitment is realistic and is met. **The requirement arrives and there are two weeks.** - Starts with whatever depends on third parties → The wait runs in parallel with the internal work. --- --- id: KB-NO-005 url: https://app.codecontract.io/help/regulation/asking-a-supplier-who-does-not-have-the-data idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-NO-002] citadoPor: [KB-NO-006, KB-NO-008, KB-NO-010] --- # When the supplier does not have the data _The commonest situation when new regulation starts, and what to do without blocking everything._ **Responde a:** my supplier cannot give me the composition · supplier without sustainability data · what to do when origin data is unavailable · non-eu supplier not responding with data You ask for composition, origin or footprint and the supplier says they do not have it. They are not lying: most likely nobody ever asked them, and they in turn depend on their own supplier. It is the commonest situation at the start and it has to be handled without stopping supply. ## What to do, in order 1. **Record that you asked** — With its date. It is what shows diligence even if the data never arrives, and it is what you will be asked about. 2. **Ask which part they do have** — It is rarely all or nothing. Often they have origin but not footprint, or the reverse. 3. **Give a realistic deadline** — If they depend on their supplier, two weeks is not enough. An impossible deadline guarantees no answer. 4. **Decide whether it changes anything** — Do you keep buying? Look for an alternative? It is a commercial decision worth taking rather than leaving open. > [!IMPORTANT] > What you must not do is fill the gap with an estimate and treat it as fact. If you pass it to a customer as a firm figure, that number carries your signature and your company answers for it, not the supplier who did not have it. ## What you can answer meanwhile "We do not hold that data as of today; we requested it from our supplier on X and expect it by Y." That is a professional, verifiable answer and far better than an invented number. Most customers accept it; those who do not are asking you to lie. > [!WARNING] > If several customers ask for the same data, do not chase it separately. One case per supplier with the request made once serves to answer all of them, and stops the supplier receiving the same request four times. > [!NOTE] > The sooner you start asking, the less it hurts. Suppliers who lack it today will acquire it, and those asking you will do so on ever shorter deadlines. **Can I require it contractually?** On future renewals it is standard; check with your adviser. **What if they never provide it?** That is information for a commercial decision. The case at least proves you asked. **Is an unsupported declaration from them enough?** It depends on the data and who you pass it to; ask before assuming it suffices. ## Ejemplos **A manufacturer receives the same origin request from three customers and lacks it from eight suppliers.** - Launches a single request per supplier with a two-month deadline - Tells all three customers what it has and when the rest will come → Keeps all three customers without inventing a figure, and two months later holds six of the eight. **The supplier says they do not have the data and it stops there.** - Records the request and the reply → The gap is a documented finding rather than silence. **The whole file is blocked over one missing figure.** - Moves on with the rest and flags that point → What can be completed is completed. **The supplier does not understand what is being asked.** - Explains the data point with an example → The reply arrives on the second request. **The data sits with your supplier's supplier.** - Asks them to pass it back up the chain → The chain is walked to where the data is. **An estimate is invented to fill the gap.** - Declares it as an estimate and on what basis → What is declared is defensible. --- --- id: KB-NO-006 url: https://app.codecontract.io/help/regulation/where-to-start-with-new-regulation idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-001, KB-NO-005] citadoPor: [KB-NO-007, KB-NO-011] --- # Where to start with new regulation _The four steps that work with any of them, before knowing whether it applies to you._ **Responde a:** new regulation affects me what do i do · where to start with a new obligation · how to prepare for regulation coming into force · i do not know if this rule applies to me New regulation arrives and the first reaction is to check whether it applies to you. That is logical and usually a pit: the texts are long, the timelines are staged and concrete answers cost money. These four steps work before you know, and none is wasted if it turns out not to apply. ## The four 1. **Find out who will know before you do** — Your trade association, your certification body or your largest customer. Almost always one of those three is already asking. 2. **Look at what information it asks for, not what it obliges** — Nearly all ask the same: composition, origin, who did what and when. That can be gathered without deciding anything. 3. **Start asking your suppliers** — It takes longest and does not depend on you. Asking early costs nothing if it later turns out unnecessary. 4. **Ask the specifics of whoever should answer** — With the first three done, that consultation is shorter, cheaper and more useful. > [!IMPORTANT] > The order matters. Almost everyone starts at step four, paying for advice on whether it applies, and reaches step three six months later — which is when they discover their suppliers need another six to answer. ## What is never wasted **En corto** - Knowing what your product is made of. - Knowing where each component comes from. - Being able to prove when you asked for something and when it arrived. None of the three depends on which rule ends up applying. They are useful under any of them, and they are what your customers will ask for even if no authority ever does. > [!WARNING] > Be wary of anyone selling you a solution for a specific rule before its timelines and scope are settled. What is certain is that you will be asked for supply-chain data; the wrapper will change. > [!NOTE] > This help centre cannot tell you whether a rule applies to you, and nobody who does not know your case should either. What it can do is help you arrive prepared to that conversation. **What if I start and it does not apply?** You will have gathered supply-chain information customers will ask for contractually anyway. **Can I wait until everything is clear?** You can, and it is a legitimate decision. The cost is that third-party data takes months to arrive. **Who confirms it for me?** Your adviser, your trade association or your certification body. ## Ejemplos **A company pays for advice on whether new regulation applies and waits three months for the answer.** - Meanwhile starts asking suppliers for composition and origin → When the answer arrives it already holds half the data, instead of starting then. **You start by trying to understand the whole rule.** - Starts by inventorying what information already exists → Less turns out to be missing than it seemed. **The adviser is consulted with no data to hand.** - Brings the inventory to the consultation → The consultation is short and specific. **You wait for the date to arrive before starting.** - Requests early whatever depends on third parties → The wait does not pile up at the end. **Each department prepares their part separately.** - Gathers the information in one file → There is one picture, not four. **Nobody knows exactly what is missing.** - Keeps a list of gaps with an owner → Progress is visible without meetings. --- --- id: KB-NO-007 url: https://app.codecontract.io/help/regulation/labelling-and-what-your-product-claims idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-001, KB-NO-006] citadoPor: [KB-AL-007, KB-IU-009, KB-NO-015, KB-NO-018, KB-NO-024] --- # Labelling and what your product claims _Every claim on a label has to be backed by a document._ **Responde a:** what can i put on the label · product environmental claims · claiming recyclable requirements · greenwashing what documentation do i need Everything a label says is a claim someone can ask you to prove: that it is recyclable, that it contains recycled content, where it comes from, that it meets a standard. The label is the easy part; the paperwork behind it is not. ## Each claim, its backing | If you claim… | You need… | Who holds it | | --- | --- | --- | | Composition or material | The supplier's data sheet, current | Your supplier | | Recycled content percentage | A declaration or certificate with its date | Your supplier, sometimes with testing | | Origin | Upstream traceability documentation | The whole chain, and it takes longest | | Compliance with a standard | Certificate or declaration of conformity | A body or yourselves | | Any environmental benefit | Specific backing for that specific claim | Depends what you claim | > [!IMPORTANT] > The last row is where most companies get into trouble unintentionally. Generic environmental claims — "environmentally friendly", "sustainable" — without concrete, verifiable backing are increasingly scrutinised, and responsibility sits with whoever places the product on the market, not the supplier who said it verbally. ## The practical rule Before putting something on a label, ask: if tomorrow I am asked to prove this, with what document and who has to give it to me? If the answer is "I will ask the supplier", ask before printing the label, not after. > [!WARNING] > Supplier changes are where this breaks. If you change the supplier of a component and the label keeps making the same claim, that claim may have stopped being true without anyone noticing. ## Frameworks cited Consumer information, environmental claims and their substantiation, product-specific labelling rules, and where applicable the requirements of any certifications you use as an argument. What you may claim and with what backing is confirmed by your adviser: this only explains how to have the backing gathered and dated. > [!NOTE] > Marking backing documents for annual review is what stops a label printed three years ago from still claiming something no longer supportable. **Is a supplier declaration enough?** It depends on the claim; some need testing. Ask before assuming. **What if the supplier changes the formula?** The claim may stop being true: hence periodic review. **Who answers if a claim is false?** Usually whoever places the product on the market; confirm for your case. ## Ejemplos **A company changes packaging supplier and keeps the label with the previous recycled content figure.** - Requests the new supplier's data sheet before printing more - Marks the sheets for annual review → Spots that the figure has changed before anyone asks. **The label claims something and nobody knows what backs it.** - Links each claim to its document → Every line on the label has its paper behind it. **The supplier changes and the claim stops being true.** - Reviews labels when suppliers change → The label keeps telling the truth. **A client asks you to evidence one specific claim.** - Checks that reference's file → You answer without searching email. **The label is approved without reviewing what it claims.** - Reviews claim by claim before printing → Reprinting a whole run is avoided. **The document backing a claim expires.** - Records its validity when filing it → The warning arrives before the label stops being true. --- --- id: KB-NO-008 url: https://app.codecontract.io/help/regulation/auditing-your-own-suppliers idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-NO-005] citadoPor: [KB-IC-015, KB-NO-021] --- # Auditing your own suppliers _When the demand reaching you has to be passed upstream._ **Responde a:** audit my suppliers · supplier sustainability questionnaire · how do i require from my supplier what is required of me · second-party audit The moment comes when the demand you receive from a customer has to be passed to your suppliers. And there you discover what your customer already knew: asking is easy, getting it delivered is not. ## The three levels of demand, and what each costs | Level | What you ask | What response you get | | --- | --- | --- | | Declaration | That they sign they comply | High. Almost everyone signs | | Evidence | That they prove it with documents | Medium. The organised ones do | | Audit | Going to see it | Low, and expensive. Only for critical ones | > [!IMPORTANT] > Start at level one with everyone and escalate only with those who matter. Demanding level three from two hundred suppliers is not rigour: it is an expensive way of achieving nothing, because you cannot audit two hundred and they know it. ## How to decide who escalates **En corto** - By what is at stake with that supplier, not by their size. - By whether their failure shows immediately or takes months to surface. - And by whether you have an alternative, which changes the whole conversation. > [!WARNING] > A supplier who signs a declaration and does not comply leaves you worse off than one who honestly says they cannot: with the signed declaration you accepted something you never checked, and that is on record. ## What makes them respond The same as any request: ask for little and specific, with the full name of what you want, a real deadline, and a reason that matters to them. "Our customer requires it of us" works better than you would think: most understand because the same happens to them. > [!NOTE] > Keep the request even if no answer comes. Before your customer, "we asked on X and received nothing" is a very different position from "we did not ask". **Can I require it contractually?** On renewals it is standard; check with your adviser. **What if a critical supplier refuses?** That is information for a commercial decision, and worth taking expressly. **Does a third-party audit help?** It is usually most efficient for critical suppliers, and avoids duplicating effort with their other customers. ## Ejemplos **A company demands documentary evidence from its 180 suppliers and 40 respond.** - Keeps the signed declaration for everyone - Escalates to evidence only with the 20 critical ones → Gets 18 of the 20 that matter, instead of 40 scattered among those that do not. **Suppliers are asked for less than is asked of you.** - Passes the same list back up the chain → The gap stops sitting on your balance sheet. **Each supplier replies in a different format.** - Requests specific documents to a single destination → What is received can be compared. **Chasing thirty suppliers occupies a person.** - Requests and chases automatically → That person reviews instead of nagging. **A client asks about one supplier by name.** - Checks that supplier's file → You answer with a list rather than an enquiry. **A supplier's documentation expires without warning.** - Records third-party expiries too → The gap closes before the question. --- --- id: KB-NO-009 url: https://app.codecontract.io/help/regulation/extended-producer-responsibility idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-003, KB-NO-002] citadoPor: [KB-NO-012, KB-IU-011] --- # Extended producer responsibility _What information has to be declared and where it comes from, without judging what applies to you._ **Responde a:** extended producer responsibility documentation · declaring packaging placed on the market · collective compliance scheme data · epr what do i have to declare Whoever places a product on the market is also responsible for what happens to it when it stops being used. In practice that means periodically declaring quantities and materials — and that declaration depends on data your suppliers hold. ## Where each item in a declaration comes from | Data | Who holds it | How to get it | | --- | --- | --- | | Quantity placed on the market | You | From your sales system | | Weight per packaging unit | Your supplier | Technical sheet, and it changes if packaging changes | | Material and composition | Your supplier | Declaration, with its date | | Recycled content, where applicable | Your supplier, sometimes with testing | Certificate | > [!IMPORTANT] > The last three rows are not yours, and they decide whether a declaration comes out right. Requesting them when the declaration is due is late: that is the moment you discover the supplier changed material eight months ago and nobody noted it. ## What breaks a declaration **En corto** - A supplier change without updating the data sheet. - A packaging format change nobody communicated. - And estimated weights "because the real one never arrived". > [!WARNING] > Declaring with estimates presented as real figures is the costliest error, because it goes on record with your signature. If you do not hold a figure, the conversation is with your supplier and your adviser, not with the spreadsheet. ## Frameworks cited Extended producer responsibility and its reporting duties, collective compliance schemes and their declaration requirements, and packaging and waste rules. What you must declare, how often and to whom depends on your product and country: confirm with your adviser or your compliance scheme. > [!NOTE] > Marking packaging data sheets for annual review and re-requesting them on supplier change is the only thing that stops next year's declaration being an investigation. **What if the supplier will not give me the exact weight?** It is their technical sheet; if they lack it, that says something about that supplier. **How often is it declared?** It depends on the regime applying to you; check. **Is last year's sheet enough?** Only if the packaging has not changed, and you must be able to assert that. ## Ejemplos **A company prepares its annual declaration and finds two packaging items changed material.** - Requests the new sheets and marks all of them for annual review → Next year's declaration takes an afternoon instead of a three-week investigation. **The figure to declare sits in three different systems.** - Gathers it into one file through the year → The declaration is prepared without a campaign. **A supplier's figure is missing at the last moment.** - Requests it as it is generated → The deadline does not depend on somebody else's diary. **A figure is declared and no supporting evidence is kept.** - Stores the evidence with what was declared → The later review has something to answer with. **Nobody knows how last year's figure was calculated.** - Records the basis alongside the calculation → The figure is explicable years later. **Part of it is estimated without saying so.** - Declares which part is an estimate and on what basis → What is declared is defensible. --- --- id: KB-NO-010 url: https://app.codecontract.io/help/regulation/proving-where-a-raw-material-came-from idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-NO-005] citadoPor: [KB-IU-010, KB-NO-016, KB-NO-022] --- # Proving where a raw material came from _What you must be able to show when origin stops being data and becomes an obligation._ **Responde a:** prove where timber came from · raw material traceability · due diligence declaration · documenting raw material origin For several raw materials — timber, paper and board, palm oil, soy, cocoa, coffee, rubber, and cattle linked to them — origin has moved from commercial information to a documentary obligation. With one uncomfortable detail: the country is not enough, you must be able to point to the plot. ## What you must be able to show | Element | What it means in practice | | --- | --- | | Where it was produced | Plot coordinates, not the region | | When | Production date or period | | Who sold it | The full chain down to you, with no gaps | | What you checked | Your risk assessment and what you did about it | > [!IMPORTANT] > The fourth is the one almost everyone forgets and the only one that depends solely on you. The first three must be given to you; the fourth you produce, and its absence is what turns an incomplete file into a breach. ## Where to start if you have nothing yet 1. **List what you buy that is affected** — Usually fewer items than expected: three or four references. 2. **Look at who sells it to you** — A large importer will already hold the file; a small intermediary probably will not. 3. **Ask everyone the same thing, in writing** — An identical request is what makes the answers comparable. 4. **And keep the refusals too** — A supplier who cannot provide origin is a decision you have to take, and it helps to record when you knew. > [!WARNING] > The usual blind spot is the processed product. If you buy ready-made packaging, the obligation does not vanish because you never saw the tree: it travels with the product. ## How it holds up over time **En corto** - Every incoming batch, with its origin documentation linked. - A periodic review of affected suppliers, not a one-off campaign. - And a warning when a declaration expires or the supplier changes origin. > [!NOTE] > This fits what you already do for other things: per-supplier documentation, with expiry and reminders. What is specific is what you ask for and how precisely, not the mechanism. **Is a signed supplier declaration enough?** It is the starting point, not the end: you must be able to back it up. **What if the supplier is outside the EU?** The obligation falls on whoever places the product on the market; usually you. **How long must it be kept?** Years, not months. Keep it where it can be found, not in an inbox. ## Ejemplos **A packaging firm finds its board is affected and its supplier cannot give coordinates.** - Sends the same written request to all three suppliers - Records the refusal with a date and assesses the risk → Switches supplier with a documented reason, instead of finding out during an inspection. **The origin is asserted by the supplier and nothing more.** - Requests the document that backs it → The claim stops being only a claim. **Consignments of different origins get mixed.** - Records which consignment went into which production → You can say what came from where. **A client asks about the origin of a specific shipment.** - Checks that delivery's file → You answer per delivery rather than per catalogue. **The supplier changes origin and does not say so.** - Asks them to report any change → The change arrives before the question. **The origin document is filed by supplier.** - Also files it against the consignment → You answer for a specific shipment. --- --- id: KB-NO-011 url: https://app.codecontract.io/help/regulation/obligations-that-arrive-on-a-date idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-001, KB-NO-006] citadoPor: [KB-TZ-017] --- # Obligations that arrive on a date _E-invoicing, sustainability reporting, product passports: how to prepare without guessing._ **Responde a:** when does e-invoicing become mandatory for me · preparing for regulation coming into force · digital obligations timeline · which regulations apply to our size Every so often an obligation appears with a date: from such a day you must issue differently, report something new, or be able to prove something nobody used to ask for. And it almost always arrives by pull-through before it arrives by law: a large client demands it two years before the rule does. ## The pattern always repeats | Phase | What happens | What to do | | --- | --- | --- | | It is approved | A distant date, little practical detail | Note the date and who in the company tracks it | | It approaches | Large clients start asking for it | Prepare via that route, not the legal one | | It phases in | Large companies first, then the rest | Know which phase you are in — not always obvious | | It is enforceable | No room left | It should have been done months ago | > [!IMPORTANT] > The second row is the useful one. When a large client asks for something "to get ahead", that is the real warning: what is a commercial requirement today will be an obligation, and you now have a concrete reason to build it. ## How to prepare without overspending 1. **Find out which phase you fall into** — It depends on size, sector or turnover, and there is usually an extension nobody remembers. 2. **Check how much of it you already have** — Usually quite a lot: what is missing is the form, not the data. 3. **Start with what pays off regardless** — Traceability, or current per-supplier documentation, is worth having with or without the rule. 4. **And record when you started** — If you run late, being able to show when you began is what separates a delay from neglect. > [!WARNING] > Do not buy tools "to comply with regulation X" until you know your phase and what your main client actually requires. Half those purchases happen two years early and with a scope that later changes. ## What almost all of them ask for underneath **En corto** - Being able to show the origin and journey of something. - Keeping third-party documentation current and dated. - And being able to show who did what and when, without reconstructing it. Which is why working on those three fronts pays off for whatever comes: they are the common denominator of nearly all of them, and none is satisfied by an isolated document. > [!NOTE] > Specific regulations change and their dates move. What does not change is that they arrive asking for evidence, not declarations — and evidence is generated while you work or not at all. **How do I know if it applies to us?** Ask your advisers about the phase and your main client about their timeline. **What if we are very small?** Many start with large companies, but they reach you through the chain before the law does. **Is getting ahead worth it?** If a client is already asking, yes. If nobody is, build the foundations and wait. ## Ejemplos **A small firm hears a new obligation is coming and considers buying a tool.** - Checks its phase and asks its main client - Starts by getting supplier documentation current → Reaches the date prepared, without having bought something that later did not fit. **You wait for the date before starting to prepare.** - Starts with whatever depends on third parties → The wait runs in parallel. **Nobody knows which dates affect the company.** - Keeps a list of dates with an owner → None arrives as a surprise. **The date approaches and supplier information is missing.** - Requests early and chases automatically → The deadline does not depend on somebody else's diary. **Everything is prepared and then the deadline moves.** - Reviews the dates periodically → The work follows the real calendar. **Each department finds out separately.** - Shares the calendar in one place → Nobody duplicates and nobody is left out. --- --- id: KB-NO-012 url: https://app.codecontract.io/help/regulation/packaging-and-waste-in-a-small-company idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-NO-009, KB-NO-026] citadoPor: [KB-NO-003] --- # Packaging and waste in a small company _The minimum you must be able to show without setting up a department for it._ **Responde a:** packaging obligations for small companies · small business waste documentation · packaging declaration what to keep · waste contractor paperwork Packaging and waste obligations are almost always explained with large industry in mind, which leads a fifteen-person company to conclude either that none of it applies or that all of it does. Usually the first is partly true and the second far less than feared. ## The three fronts, in a small company | Front | What you must be able to show | How often | | --- | --- | --- | | What you place on the market | How many packages and of what material | Annually, if you must declare | | What you generate | Which wastes, how much, and to whom | Every collection | | Who you give it to | That they are authorised and the authorisation is current | Periodic checking | > [!IMPORTANT] > The third is the only one that can become a serious problem and the easiest to solve: request the contractor's authorisation, keep it with its expiry date, and have it warn you when renewal is due. Handing waste to someone unauthorised is your responsibility, not theirs. ## What to keep for each collection **En corto** - The document evidencing the transfer, with a date. - What was collected and how much. - And who collected it, with their authorisation current that day. With that, an inspection's three questions are answered by opening a file. Without it, they are answered by hunting for delivery notes in an invoice folder. ## How to organise it without assigning anyone 1. **One file per contractor** — With their authorisation and its expiry inside. 2. **Each collection, with its document linked** — A photo of the note at collection is fine: what matters is that it does not stay in a pile of paper. 3. **An annual reminder for anything to declare** — It is the forgotten one, because it happens once a year. 4. **And packaging figures, if applicable, as you invoice** — Reconstructing a whole year in December is what makes it seem impossible. > [!WARNING] > Do not assume "the accountants handle it". They file declarations with the data you give them; checking that the waste contractor is authorised and keeping the transfer documents are yours. > [!NOTE] > If you sell packaged product to other countries, obligations vary by country and sometimes require local registration. It is where most small companies discover an obligation late. **Does it apply if we only have an office?** Office waste has its own route; the burden is far lighter. **How long must documents be kept?** Years. It is among the most requested in inspections. **What if the contractor loses authorisation?** You must stop handing them waste: hence the expiry date matters. ## Ejemplos **A fifteen-person company files waste notes with its invoices.** - Opens a file per contractor with authorisation and expiry - Links each collection to its document → Answers an inspection in minutes and catches an authorisation expiry in time. **A long procedure is set up for a company of eight people.** - Keeps what is already generated and organises it → The essentials are covered without a department. **Receipts sit in a physical folder.** - Captures and stores them in the file → They are found without going to the cabinet. **Nobody knows what was removed last year.** - Checks the history by period → The figure exists when it is asked for. **A receipt is lost and cannot be chased.** - Keeps its own copy on receipt → You do not depend on the contractor's archive. **What is missing is discovered on the day of a visit.** - Reviews the file once a quarter → Gaps are closed with time to spare. --- --- id: KB-NO-013 url: https://app.codecontract.io/help/regulation/sending-workers-to-another-country idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-CN-005] citadoPor: [KB-LE-018, KB-NO-023] --- # Sending workers to another country _An installation, a site or a service abroad: documentation travels with the person, and ahead of them._ **Responde a:** posting workers abroad documentation · prior posting declaration · posted worker requirements · overseas installation paperwork Sending three people abroad to install something for two weeks looks like a logistics matter, and it is mostly a documentary one. Some obligations must be met **before** they leave, and an inspection at destination may ask on site for papers that sit in your office. ## What is usually required | Document | When | Where it must be | | --- | --- | --- | | Prior posting declaration | Before departure | Filed at destination | | Applicable social security legislation document | Before departure | With the person | | Contract and applicable terms | Before departure | Accessible, often translated | | Role training and fitness | Valid on those days | With the person | | And a reachable representative | During the posting | Designated in writing | > [!IMPORTANT] > The last row surprises most: many countries require designating someone reachable during the posting, and "call head office" does not satisfy it. It is a formal requirement met with a name and a contact, and almost nobody prepares it. ## Why it gets complicated in practice 1. **Requirements vary by country** — And by sector. What worked in one does not work in the next. 2. **They change without notice** — What you did two years ago may be out of date. 3. **Documentation is requested on site** — On a site, to an inspector, with a phone as the only tool. 4. **And it must be provable afterwards** — Sometimes months later, once the posting has ended. > [!WARNING] > The expensive mistake is preparing the posting with documentation in a folder on an office computer. If the inspector asks at destination and the person cannot show anything from their phone, the result is the same as not having it. ## How to organise it **En corto** - One file per posting, not per person or per project. - With who travels, their documents valid on those days, and the filed declaration. - Accessible from the traveller's phone. - And kept afterwards, with dates on everything. > [!NOTE] > The same applies in reverse: if you host workers from a foreign company at your premises, you will need to be able to evidence that you checked their documentation. **Does it apply to a two-day trip?** It depends on the country and the work; many do not distinguish by duration. **What if they are self-employed rather than staff?** The documents change, not the obligation to evidence it. **Who should know the requirements?** A specific person in your company; delegating it entirely to the destination client does not exempt you. ## Ejemplos **A company sends three installers abroad with the paperwork left at the office.** - Opens a per-posting file accessible from a phone - Designates the reachable representative in writing → The inspection at destination is resolved on site and there is a record for afterwards. **Who travels is decided the week before.** - Checks per person what documentation is current → The trip is not discovered blocked at the airport. **The documentation travels with the person on paper.** - Also keeps it accessible from a phone → A lost paper stops halting the work. **Somebody changes at the last minute.** - Keeps more people current than actually travel → The change is resolved by picking somebody who can go. **The destination client asks for different papers.** - Asks for the list before preparing anything → You prepare what they ask for there, not what applies here. **Nobody knows what expires before the trip.** - Warns about expiries in advance → Renewals happen before travelling. --- --- id: KB-NO-014 url: https://app.codecontract.io/help/regulation/client-security-questionnaires idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-IC-010, KB-NO-021, KB-NO-027] citadoPor: [KB-AD-016] --- # Client security questionnaires _A large client sends a hundred questions about how you handle their information. How to answer without dying trying._ **Responde a:** client security questionnaire · they are asking for iso 27001 · answering a supplier security assessment · vendor risk assessment questions A questionnaire arrives from a large client with dozens or hundreds of questions about how you store their information, who accesses it and what would happen if something failed. Frameworks such as ISO 27001, NIS2 or the GDPR appear by name, and the typical reaction — answering fast so as not to stall the contract — is what gets paid for later. ## The four blocks that repeat | Block | What they ask | What answers it | | --- | --- | --- | | Who has access | How access is granted and removed | Your policy and the activity log | | Where the data is | Location, providers, subprocessors | The list of who you use and for what | | What happens if something fails | Backups, recovery, incident notification | Your plan, however short | | And what certifications you hold | Current certificates and their scope | The certificate, with its scope and date | > [!IMPORTANT] > The second half of that last row sinks many companies: holding a certificate is not enough, you must state **what it covers**. A certificate covering one site or one service, presented as if it covered the whole company, is spotted on first review and costs credibility for everything else. ## How to answer without redoing the work each time 1. **Keep the answers you gave, not only the questionnaire** — 80% of questions repeat between clients; answering from scratch each time is the expensive mistake. 2. **With the date of each answer** — What was true two years ago may not be; an undated answer gets copied and ages by itself. 3. **With who validated it** — Technical answers are validated by whoever knows, not by whoever fills in the form. 4. **And without promising what you do not do** — Ticking "yes" for something you have not built becomes a contractual breach the day it is checked. > [!WARNING] > The fourth point causes the most trouble and is done most often without noticing. One extra "yes" in a questionnaire is not sales optimism: it becomes part of what you have declared to that client, and if there is ever an incident, your answer is compared with reality. ## What is up to you even without certifications **En corto** - Being able to say who accesses what, and prove it with a log. - Knowing which providers you give data to, and for what. - Having written what you would do in an incident, even on one page. - And being able to show that you genuinely check third-party documentation. Those four are answered with what you already do, provided it is recorded, and they weigh most in the assessment of a small company — more than holding a badge. > [!NOTE] > Which frameworks apply, their deadlines and who they bind vary by country, sector and size, and they move. What is described here is how to organise the answer; **what applies to you and from when is a question for your adviser**, not something to infer from a questionnaire. **Do we need certification to sell to a large company?** Not always; many accept answers and evidence without a certificate. Ask before investing. **Can I reuse answers from another client?** Yes, and it is sensible; what does not work is reusing them without checking the date. **What if an answer is "we do not have that"?** It is a valid answer, especially if you say what you do instead. Lying is not. ## Ejemplos **A small firm receives a security questionnaire from a large client and fills it in one afternoon.** - Keeps the answers with dates and who validated them - Corrects two "yes" answers that matched nothing in place → The next questionnaire takes two hours and declares nothing they cannot stand behind. **A hundred questions and two weeks.** - Starts from the previous questionnaire's answers → You begin from something rather than zero. **Yes is answered to something that cannot be backed up.** - Links each answer to its document → You answer what can be evidenced. **The always-attached documents are scattered.** - Gathers the company file in one place → Attaching stops being half the job. **Gaps are spotted and forgotten on submission.** - Notes what was missing as the year's agenda → The next questionnaire finds fewer gaps. **Each client asks the same on a different form.** - Reuses the same documentary base → The third questionnaire costs an afternoon. --- --- id: KB-NO-015 url: https://app.codecontract.io/help/regulation/the-declaration-of-conformity idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-007, KB-IU-004, KB-NO-025] citadoPor: [KB-NO-018, KB-NO-022, KB-NO-024, KB-NO-029] --- # The declaration of conformity _The document stating your product complies, who signs it, and why it cannot be copied from a supplier._ **Responde a:** what is a declaration of conformity · who signs the ce declaration · supplier sent me their declaration is that enough · technical documentation for ce marking If you place a product on the market, sooner or later someone asks for its declaration of conformity. It is a short document — it fits on one page — and also the one that causes the most misunderstanding, because it looks like a certificate someone gives you and it is not: it is a declaration you make. ## What it is and is not | It is | It is not | | --- | --- | | Your own declaration about your product | A certificate issued by a third party | | Signed by someone in your company | Something a supplier signs on your behalf | | Backed by technical documentation you keep | A loose form to fill in | | About a specific product or family | Valid for your whole catalogue | > [!IMPORTANT] > The first row changes the whole conversation: nobody gives it to you, you make it. And in signing it you take on that technical documentation exists behind it. If you are ever asked for it and have it, the next question will be about that documentation — and that is what needs preparing, not the declaration. ## The commonest mistake > [!WARNING] > Forwarding a supplier's declaration as if it were yours. Theirs covers **their** product as they place it on the market; if you transform it, assemble it with other things, or sell it under your own brand, that document no longer describes what you are placing on the market. It is spotted the moment someone compares names, and it undermines everything else you presented. ## What to keep and be able to find **En corto** - The signed declaration, with the person and the date. - The technical documentation behind it, even though it is not handed to anyone. - The declarations of components you buy, which feed it but do not replace it. - And previous versions, so you know what was declared for what you sold three years ago. The last point is always neglected and is what you need when a claim arrives about an old unit: what matters then is not what you declare today, but what you declared when that unit shipped. ## When it must be redone 1. **When the product changes** — A different component, a new version, a change of manufacturer. 2. **When what is required of it changes** — The references the declaration cites can be updated. 3. **And when who places it on the market changes** — If you start selling it under your own brand, the declaration is yours from that day. > [!NOTE] > Which products need a declaration, exactly what it must cite and what technical documentation must be kept depends on the product type and the market, and it gets updated. **Confirm that with your adviser or the relevant body**; what is explained here is the documentary mechanics: who signs, what backs it, and what you must be able to show years later. **Can anyone sign it?** Someone able to bind the company. Not the salesperson who emails it. **Is English acceptable?** It is usually required in the language of the country of sale; ask before translating. **Must it be given to the customer?** Often yes, and in many cases it accompanies the product. Keep a record of who it was sent to. ## Ejemplos **A company sells under its own brand equipment assembled from bought-in components.** - Stops forwarding the component maker's declaration - Issues its own and keeps the technical documentation behind it → When a large client asks, it hands over a document describing what it actually sells. **The supplier's is copied with the name changed.** - Issues its own, on its own file → The document says what you can stand behind. **Nobody knows who should sign it.** - Clarifies it with the adviser before issuing → The signature belongs to whoever can give it. **It is issued and nothing backing it is kept.** - Stores the technical file alongside it → The cover page has what supports it behind. **The product changes and the declaration stays the same.** - Reviews the declaration with every change → The document describes what is sold today. **A client asks for the declaration of an old version.** - Keeps each version with its date → You provide the one that covered that sale. --- --- id: KB-NO-016 url: https://app.codecontract.io/help/regulation/when-you-are-asked-for-sustainability-data idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-NO-010] citadoPor: [KB-IU-013] --- # When you are asked for sustainability data _A large client sends an environmental questionnaire. What you can answer with what you already have, and what not to invent._ **Responde a:** client environmental questionnaire · they ask for our carbon footprint · sustainability data for a supplier · sme sustainability reporting Increasingly, a large client that buys from you asks for environmental data: consumption, waste, material origin, sometimes footprint. They are not asking out of conviction: it is being asked of them and they need the part that comes through you. And most of those questions are answerable with what you already have, if it is findable. ## The three kinds of question, and where each answer comes from | Kind | Example | Where the answer comes from | | --- | --- | --- | | What you already measure by obligation | Waste handed to a contractor, invoiced consumption | Your own documents | | What you know but have not gathered | Which materials you buy and from whom | Supplier documentation | | What has to be calculated | Footprint attached to a product or a shipment | A calculation with criteria, not a document | > [!IMPORTANT] > The difference between the first two and the third is what keeps you out of trouble. The first two are **collection**: you have the data and need to assemble it. The third is a **calculation with assumptions**, and a figure calculated with no method behind it becomes a claim you will have to sustain every year and that a client may ask to have audited. ## How to answer without over-committing 1. **Separate measured from estimated, and say so** — "Actual invoiced consumption" and "estimate based on X" are two different answers, and both are valid when labelled. 2. **Answer with the period and the source** — A figure with no period or origin is useless to the recipient and forces you to redo it. 3. **Do not promise improvements you have not decided** — A commitment in a questionnaire ends up in next year's contract. 4. **And keep what you answered, dated** — Next year they will ask the same and you will have to be consistent. > [!WARNING] > Point four catches most companies in year two. A questionnaire answered from memory today and another answered from memory twelve months later almost always contradict each other — and to the client, that contradiction matters more than either figure. Keeping your answers is not bureaucracy: it is what makes the second answer defensible. ## What you already have that helps **En corto** - Waste transfer documents and who collects it. - Consumption from your own utility invoices. - Origin and certifications of the raw materials you buy. - And transport documentation, if they ask about shipments. Those four cover most of a typical supplier questionnaire. What they do not cover is exactly what is worth reviewing with someone before answering. > [!NOTE] > Sustainability reporting frameworks, who they bind and from when are moving, and what is voluntary for you today may arrive through your client before it arrives through the rules. **What applies to you and with what scope is a question for your adviser**; this only describes how to organise the answer with what already exists in your documents. **Can I say we do not measure it?** Yes, and it beats inventing it. Add what you do measure and since when. **Do we need certification?** To answer a questionnaire, hardly ever. Ask before investing. **What if the client insists on data we do not have?** Then it is a business decision: calculate it with a method, or say it is not available. ## Ejemplos **A small firm receives an environmental questionnaire from its largest client and considers estimating figures.** - Answers with what is measured and labels what is estimated - Keeps the answers with their period and source → The following year it answers in an afternoon without contradicting itself, which is what the client checks. **Figures nobody can back up are given.** - Answers with what is already measured, and says so → What is declared holds up. **What is not held is left blank.** - Explains what is not yet measured and from when it will be → An explained gap reads as a footnote. **The data sits in invoices and delivery notes, ungrouped.** - Gathers what already exists into a file → There turns out to be more than it seemed. **Every year it is rebuilt from scratch.** - Keeps what was answered with its evidence → The following year starts from there. **A figure depends on a supplier who does not reply.** - Records the request and the reply → The gap is documented rather than blank. --- --- id: KB-NO-017 url: https://app.codecontract.io/help/regulation/obligations-a-client-passes-down-to-you idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-LE-013] citadoPor: [KB-NO-028] --- # Obligations a client passes down to you _What you sign in their contract can turn their obligation into yours, and that cannot be undone later._ **Responde a:** the client contract imposes more on me · compliance clauses in a supply contract · they require what is required of them · accepting supply chain obligations A growing share of what is required of you does not come from a rule that applies to you: it comes from a contract. Your client has obligations and passes them downstream, and the moment you sign, those obligations stop being theirs and become contractually enforceable against you. ## The clauses most often signed unread | What it says | What it really implies | | --- | --- | | "Shall comply with applicable law" | Generic and reasonable; the problem is the next ones | | "Shall flow these obligations down to its suppliers" | You must do to yours what they are doing to you | | "Shall facilitate audits, including of its chain" | You may have to open up what is not yours | | "Shall notify any incident within a period" | A contractual clock that runs whether or not anyone remembers | > [!IMPORTANT] > The second row generates the most work and is the least quantified at signing. Accepting flow-down means building with your suppliers the same control being built on you — same requests, same renewals, same chasing. It is not a clause, it is a process to sustain for the life of the contract. ## What to check before signing 1. **What you are asked to do, not what you are asked to comply with** — Complying with a rule is one thing; evidencing it quarterly to someone is another. 2. **How often and to whom** — That is what turns a clause into recurring workload. 3. **What happens if one of your suppliers will not cooperate** — Because you will answer for it, and it helps to know your margin. 4. **And which clocks start running by themselves** — Notifications and incidents: contractual deadlines do not send reminders. > [!WARNING] > The nuance that surprises when it lands: **a contractually flowed-down obligation binds you even if the original rule does not apply to you**. You may fall outside a framework's scope by size or sector and still have to meet it for that client, because you signed. And it works both ways: if you flow it down to your suppliers, they are bound to you the same way. ## What to have in place if you accept **En corto** - A list of what each client requires, per client: they do not all ask the same. - Notification deadlines, as alerts rather than good memory. - The chain downstream, with the same renewals demanded of you. - And evidence of having done it, which is what the audit asks for. The first avoids the costliest mistake: applying your strictest client's criteria to every supplier. It is done for convenience and multiplies the work with nobody asking for it. > [!NOTE] > Which frameworks apply to you by activity and which only by contract is a distinction with consequences, and it is not always obvious in the text. **Before signing broad compliance clauses, have your adviser read them**; after signing, it is no longer a question but an obligation. **Can they be negotiated?** Often yes, especially audit frequency and scope. **What if the client changes its requirements midway?** It depends what was signed: check whether the contract lets them update unilaterally. **Must everything be flowed down to small suppliers?** Only what you are required to flow down, and adapted: asking the impossible guarantees nothing arrives. ## Ejemplos **A company signs a framework contract with a flow-down clause.** - Quantifies what it will have to require from suppliers before signing - Sets up renewals only for the affected suppliers → It meets that client's terms without applying them to the other eighty suppliers. **The contract is signed without reading the documentation annex.** - Reviews what documentation it commits to before signing → You know what the company is committing to. **What was signed depends on a supplier who does not know.** - Passes it to the supplier in writing → The chain holds from the outset. **An impossible requirement is signed.** - Negotiates it before signing → The commitment is realistic. **Nobody knows what was committed to each client.** - Stores the commitments with the contract → It can be consulted without rereading the whole contract. **The requirement changes at renewal and goes unnoticed.** - Reviews the annexes at every renewal → No new commitment is inherited unknowingly. --- --- id: KB-NO-018 url: https://app.codecontract.io/help/regulation/the-same-product-in-several-countries idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-015, KB-NO-007] citadoPor: [KB-NO-025] --- # The same product in several countries _The product is identical and the documentation is not. What decides is the destination market, not yours._ **Responde a:** selling the same product in another country · documentation to export a product · what changes when selling abroad · the importer asks for different papers The first export is prepared like a sale that happens to be further away. Commercially, it is. Documentation-wise it is not: the same product, from the same factory and the same batch, may need different papers depending on where it goes — and it is not you or your client who decides, it is the destination market. ## What repeats and what changes | Element | Does it change by country? | What it means | | --- | --- | --- | | The product itself | No | Same batch, same factory, same controls | | What must be declared about it | Yes | Each market requires its own statements | | The label's language and content | Yes | And it is usually the first thing rejected on arrival | | Who answers to the local authority | Yes | Often a local importer or representative, not you | | What you will be asked for later | Yes | And that representative will ask, on their deadlines | > [!IMPORTANT] > The fourth row is the surprising one and the one that strains relationships most: **in many markets it is the importer who answers to the local authority**, so requests reach you not from a regulator but from your own client — and they arrive urgently, because deadlines are running for them that you cannot see. They are not becoming demanding: they are passing on an obligation of their own. Understanding that changes the tone of the conversation entirely. ## How to organise it without duplicating everything 1. **One shared product file** — Tests, composition, controls: none of that changes by destination. 2. **And a folder per market with the specifics** — Label, declarations and who the representative there is. 3. **With the label version used on each shipment** — If anything is reviewed, it is reviewed against that one. 4. **And the importer's requests in the same place** — They tend to repeat yearly and different people answer them. > [!WARNING] > A practical detail that saves complaints: **the same product may be sold under different names in each market**, and if your system treats those as separate products you end up with fragmented documentation for one identical thing. Keep one internal reference with the trade names hanging off it. When a query comes in under the local name, it is settled in a minute rather than a morning. ## What to ask before the first shipment **En corto** - Who is registered as responsible at destination and what they need from you. - What the label must say and in which language. - And what they can be asked for, because they will end up asking you. > [!NOTE] > Which requirements apply in each market, who must be registered as responsible and what documentation travels with each shipment are governed by destination rules and trade agreements. **Your adviser or customs broker settles that**; the point here is organising your side so that answering does not depend on who happens to be in that day. **Is one declaration valid for every country?** Rarely: what must be declared, and to whom, changes. **Can I just use a translated label?** Translating is not adapting. The required content changes too. **What if the importer changes?** That market's part is redone; the shared file stays as it is. ## Ejemplos **A manufacturer starts selling in two countries and creates a separate code per trade name.** - Unifies into one internal reference with trade names attached and a folder per market → A query under the local name reaches the shared documentation without duplicating anything. **The home market's documentation is sent to another country.** - Asks for the destination market's list → You prepare what they ask for there. **A document from here does not exist there under that name.** - Explains the equivalence in writing → The gap reads as a footnote rather than a failure. **Forty pages are translated that nobody asked to be translated.** - Asks what needs translating before translating → Only what is needed is translated. **Each market is prepared from scratch every year.** - Keeps the explained equivalence as a document of its own → The following year reuses it. **The same product carries different labels by country.** - Stores each version against its market → You know what was sold with which label. --- --- id: KB-NO-019 url: https://app.codecontract.io/help/regulation/when-your-waste-is-someone-elses-raw-material idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-003, KB-IU-011] citadoPor: [KB-IU-027] --- # When your waste is someone else's raw material _Selling what you used to pay to have removed is good business, and it changes entirely what you must be able to prove._ **Responde a:** selling production offcuts and scrap · my waste is another firm's raw material · by-product or waste difference · end of waste status Steel offcuts, sawdust, clean production plastic, whey: material that for years went out of the door as waste and that someone is now willing to buy. The deal makes complete economic sense, and it also brings a change of regime worth understanding before signing. ## Three situations that look alike and are not | Situation | What the material is | What is needed | | --- | --- | --- | | You hand it to an authorised manager | Waste | The usual waste traceability | | You sell it to another firm as material | Still waste until proven otherwise | The relevant recognition, before selling it | | It never became waste in your process | It may be a by-product | Proving it against criteria, not by agreement between parties | | You give it away to get rid of it | Waste, all the same | Whoever takes it to be authorised | > [!IMPORTANT] > The second row causes the most trouble, and the mistake is always the same: **calling it raw material on an invoice does not make it raw material**. Until the relevant recognition exists, the material remains waste in the eyes of the regulator, with all its traceability — and whoever handed it over answers for what it was at that moment, not for what the buyer called it. An agreement between two companies does not change a material's nature; meeting the criteria does. ## What to obtain from the buyer before the first load **En corto** - Exactly what it is and in what condition it must leave your hands. - That they can lawfully receive it in the condition you send it. - Who transports it and under what authorisation. - And what happens if a batch does not comply: they return it, they manage it, or it becomes your problem again. > [!WARNING] > The question almost nobody asks and that always comes up: **what happens when the buyer stops wanting the material?** A price change, a shutdown at their plant or a rejected batch, and suddenly you have something in the yard that nobody buys and that keeps being produced daily. Keeping the authorised-manager route alive — even unused — is what stops that week becoming a bigger problem than a year's savings. ## How it is documented while it lasts 1. **One file per material and per buyer** — With whatever evidences the condition it leaves in. 2. **Each delivery with its quantity, date and destination** — The same as you kept for waste: it does not relax because it is now sold. 3. **And any analyses or checks you run** — They are what supports each batch having complied. > [!NOTE] > When a material ceases to be waste, which status applies and what authorisations are needed is determined by the applicable waste rules and the competent authority. **Discuss this with your adviser before the first sale**, not after the first inspection; here we only explain why the conversation matters. **Can I start selling while it is being processed?** Ask first: handing it over as material without proof is the risk. **What if the buyer says they have it covered?** Have them show you: your responsibility is for what you hand over. **Does the waste record still serve?** It serves as a base, and it is worth continuing to keep it. ## Ejemplos **A company starts selling its offcuts to a processor and stops keeping outbound records.** - Keeps the per-batch record and checks in what condition the buyer may receive them → The sale remains good business and every load can be explained exactly as it left. **What used to be taken away is now sold and nothing changes.** - Reviews what documentation now accompanies each outbound movement → The movement is documented as what it is. **The buyer asks for material characterisation.** - Stores the analyses with the consignment → It is provided with the consignment rather than separately. **Consignments of different grades get mixed.** - Records what went into each output batch → You can say exactly what was sold. **The buyer asks about a consignment from months ago.** - Keeps a file for each outbound movement → You answer without reconstructing. **It is sold to several buyers with different requirements.** - Stores what was delivered to each → Each relationship has its own trail. --- --- id: KB-NO-020 url: https://app.codecontract.io/help/regulation/waste-generated-by-someone-else-on-your-premises idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-003, KB-CN-011, KB-IU-027] citadoPor: [KB-NO-026] --- # Waste generated by someone else on your premises _A contractor comes to do a job and leaves waste. Who answers for it is not always whoever produced it._ **Responde a:** waste from works at my company · the installer takes the waste away · who is the waste producer · contractor waste responsibility A refurbishment in the warehouse, a machine swap, a maintenance visit leaving used oil or filters, rubble from a small job. Someone comes, works, and when they finish there is something to remove. The question rarely asked in time is whose waste that is. ## The three situations that get confused | How it was arranged | Who manages it | What to hold | | --- | --- | --- | | Agreed the contractor takes it | They do, with their manager | The agreement in writing and their removal documents | | It stays in your skip | You do | Like any waste of your own | | Nobody discussed it | Decided once it is in the yard | The case to avoid | | The waste is hazardous | It depends, and everything changes | Check before anyone comes in | > [!IMPORTANT] > The third row creates the real problem: **if it was not agreed, the waste stays where it lands, and whoever holds the premises usually answers for it**. Whoever came to work leaves, and what remains in your yard becomes yours for practical purposes. A phone call afterwards does not fix it: the quote does, by writing down who removes it and with what documentation. One line in the contract saves the entire conversation. ## What to ask of whoever comes to work 1. **That they state what waste they will produce** — Before starting, not after: it changes who may remove it. 2. **Who removes it and to which manager** — And that the manager is authorised for that waste type. 3. **The removal documents, in your file** — Even if they manage it, the question will come to you. 4. **And what happens to whatever is not taken that day** — What stays «until next week» stays for months. > [!WARNING] > One case is especially delicate and common: **hazardous waste arriving mixed in with general waste**. A tin of solvent in the rubble skip, oily rags among packaging offcuts. From that moment the whole skip changes category, and you answer for that skip. So say where each thing goes before they start, rather than trusting the visitor to know: at their own premises it may be crystal clear and at yours they know where nothing is. ## If you are the ones working at someone else's site **En corto** - Ask who removes it before quoting: it changes the price and the liability. - Take your own away unless agreed otherwise, and record it. - And hand the client the removal documents even if they do not ask. > [!NOTE] > Who holds producer status for a waste, what duties come with it and how it is shared when a contractor is involved is determined by the applicable waste rules and by what was agreed. **Your adviser settles that before the work is signed**; here we explain why it is worth discussing beforehand. **Is the contractor saying they will take it enough?** Have them say it in writing and pass you the removal documentation. **What if unexpected waste turns up?** Stop and decide: improvising in the yard is expensive. **Does this apply to small maintenance?** Yes, and that is where it is most forgotten: filters, oils, lamps, batteries. ## Ejemplos **A company replaces a machine and the installer leaves used oil and packaging in the yard.** - Agrees in writing who removes what before the work starts → The waste leaves with whoever produced it and its removal paperwork stays on file. **An outside company leaves waste and nobody records it.** - Records what was left, when and by whom → The waste has a known origin. **It is assumed whoever generated it takes it away.** - Agrees it in writing before the work → Responsibility is decided beforehand rather than after. **The waste sits for weeks and nobody claims it.** - Flags what has sat too long → The case is faced at one month rather than one year. **It is removed mixed with your own.** - Records the origin before combining → The history stays true. **Nobody knows which companies left waste this year.** - Checks the register by supplier → The question is answered with a figure. --- --- id: KB-NO-021 url: https://app.codecontract.io/help/regulation/your-suppliers-working-conditions idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-NO-008] citadoPor: [KB-NO-014] --- # Your supplier's working conditions _A client asks how your supplier works. It is not a survey: it is a duty that has been passed down to you._ **Responde a:** asked for social data on my suppliers · supply chain due diligence · how do i know how my supplier works · human rights questionnaire for suppliers A questionnaire arrives from a large client and, among the usual questions, there are three new ones: whether your suppliers have collective agreements, whether minors work there, whether you know where their factory is. The typical reaction is to answer «nothing untoward has come to our attention» and move on. That sentence is exactly the one that does not work. **Due diligence** — The duty to LOOK, not the duty to guarantee. Nobody asks you to answer for another company's conduct: they ask you to show what you did to find out, and what you did when something surfaced. ## The three tiers, and where the problem sits | Tier | What you usually know | What you will be asked | | --- | --- | --- | | Your own company | Everything | You have it; it is familiar paperwork | | Your direct supplier | What they told you | How you verified it | | Your supplier's supplier | Almost nothing | This is where everyone falls down | | A middleman who only resells | Not even who manufactures | The most uncomfortable of the four | > [!IMPORTANT] > The answer that sinks a questionnaire is not «we have a problem» but **«I don't know»** said with nothing behind it. A client who hears «I don't know» cannot tell whether they are facing someone honest or someone who never looked. What makes the same sentence acceptable is what follows it: **«I don't know; this is what we asked, this is what they answered, and this is what we will do»**. That is an answer; the other is a silence. ## What to ask for, in order of how hard it is to get 1. **Who they are and where they actually produce** — Name, country and plant. A middleman who will not say is itself the finding. 2. **Their signed statement on labour conditions** — It proves nothing alone, but it turns a chat into a commitment. 3. **Certifications or audits, if any** — With dates: a five-year-old audit describes a factory that no longer exists. 4. **And what they do with THEIR suppliers** — The only way to reach the third tier without going yourself. > [!WARNING] > The expensive mistake is treating it as one-off paperwork: **the statement gets signed, filed, and never looked at again**. These questions are not asked once; they are asked every year and whenever something changes — a change of plant, a new subcontractor, a production peak covered by another factory. If your file holds the 2023 statement and the supplier moved plant in 2025, what you have is not evidence: it is a document asserting something that is no longer true. ## When the answer you get is a bad one **En corto** - Write down what they told you, verbatim and dated: what is recorded can be explained later. - Separate «will not» from «cannot»: two different problems, and only one is fixed by helping. - Set a deadline and a consequence, even if the consequence is only reviewing the contract. - And tell your client before they find out elsewhere: what wrecks a relationship is not the problem, it is hearing about it late. > [!NOTE] > Which companies are required to carry out due diligence, over what part of their chain and to what depth depends on size, sector and the applicable rules, and it is changing. **What applies to you is for your adviser to settle**; here we explain what you will be asked and what you need to hold in order to answer. **Do I have to audit my suppliers?** It depends on your case; what you must be able to show is what you asked and what you did with the answer. **What if my supplier refuses to answer?** The refusal is information. Record it: it forms part of the answer you give your client. **Is a statement signed by them enough?** As a starting point yes; as sole evidence no. What holds it up is having asked, dated and reviewed it. ## Ejemplos **A large client asks about labour conditions at the factory producing for you and all you know is the middleman's name.** - Asks the middleman for the plant's name and country, in writing - Records the answer and the date → The reply to the client moves from «nothing has come to our attention» to «this is what we asked and this is what we were told». **The signed statement on file is three years old and the supplier has changed plant since.** - Gives the statement an annual expiry with an alert before it lapses → The file stops holding a paper that asserts something no longer true. **A supplier flatly refuses to answer the social questionnaire.** - Records the refusal with a date and escalates it to purchasing before renewal → The refusal becomes a fact on file and a conscious decision, not a gap. **The client asks and the answer depends on the supplier.** - Passes the question on in writing and keeps the reply → You answer with what the supplier declares. **The supplier does not reply and the deadline runs.** - Records the request and its date → The gap is documented. **You answer for the supplier without asking them.** - Distinguishes your own statements from third-party ones → Every claim has an author. --- --- id: KB-NO-022 url: https://app.codecontract.io/help/regulation/buying-from-outside-the-european-union idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-010, KB-NO-015, KB-NO-028] citadoPor: [KB-NO-029, KB-DI-021, KB-LG-019] --- # Buying from outside the European Union _The goods cross the border and you start answering for them as if you had made them. That changes which papers you need._ **Responde a:** importing goods documentation · what paperwork do i need to import · as an importer what am i liable for · certificate from a non-eu supplier Buying abroad is cheaper, and almost never for the reason people assume. Part of the saving is real; another part is work the European manufacturer used to do and that now, without anyone saying so, you do. That work is documentary, and it turns up all at once the day someone asks. ## What changes compared with buying inside | What to look at | EU supplier | Supplier outside | | --- | --- | --- | | Who answers to the authorities | Usually the manufacturer | Very often you, as importer | | The certificates | Issued under the framework here | Possibly another framework, or translated | | Claiming when something goes wrong | Hard | Considerably harder | | What has to be filed | The usual | That plus the customs paperwork | > [!IMPORTANT] > The sentence to internalise is this: **on importing, you often take on the role the manufacturer had abroad**. It is not a formality — it is the difference between forwarding a question to your supplier and having to answer it yourself with documents in hand. And since the supplier is nine time zones away and sometimes changes account manager every six months, whatever you do not ask for at the start you will not get later. ## What to ask for BEFORE the first order, not after 1. **The declaration of conformity, in a language you can read** — And checking it refers to YOUR model, not to the product family. 2. **The technical documentation behind it** — The test reports, not only the handsome certificate with a stamp. 3. **Who the actual manufacturer is** — Whoever sells to you and whoever makes it are often not the same, and that matters. 4. **And a commitment to tell you if anything changes** — An unannounced component change turns your papers into old paper. > [!WARNING] > There is a much-repeated trap with certificates: **a stamp that looks like another is not the same stamp**. Documents circulate with marks resembling European ones, tests run by laboratories nobody recognises, and perfectly genuine certificates… for a different product in the same family. Checking three things filters out almost all of it: that the model number matches exactly what you buy, that the date is not earlier than the version they ship you, and that the signing laboratory exists and can be found. ## The customs paperwork worth keeping **En corto** - The import declaration and invoices, alongside the product file and not in a different folder. - The declared origin and what justified it: that is what gets reviewed years later. - And who acted as your representative, if you used one: liability is not delegated along with the admin. > [!NOTE] > Which duties an importer actually assumes, what documentation must be kept and for how long depends on the product, the country of origin and the customs regime. **Your adviser or customs agent settles that before the first order**; here we explain why it pays to ask for everything up front. **Is the certificate my supplier sends good enough?** It is if it refers to your exact model, is current, and is signed by someone identifiable. **What if I buy through a European middleman?** It changes who answers. Worth pinning down in writing before you buy. **How long do I keep import paperwork?** Longer than feels reasonable. Agree a period with your adviser and do not leave it to individual judgement. ## Ejemplos **The first order from an Asian supplier arrives and the accompanying certificate is for another model in the same family.** - Compares the certificate's model number with the order's before accepting the goods → The error surfaces on the loading bay instead of at an inspection two years later. **The supplier changes a component without notice and the filed documentation no longer describes what you sell.** - Puts a written commitment to report any change into the purchase order - Requests fresh documentation with each change → The product file keeps describing the product actually sitting in your warehouse. **You are asked for the file on a three-year-old import and the invoices sit in accounting while the certificates sit in quality.** - Keeps the customs paperwork in the same file as the product → The file is produced whole in an afternoon instead of being reassembled across two departments. **Goods are bought abroad and documentation requested on arrival.** - Requests it on the purchase order, before paying → It is asked from the only position of leverage there is. **The documentation arrives in a language nobody reads.** - Agrees the language on the order → It arrives usable from the first shipment. **A client asks you to evidence a shipment from two years ago.** - Files documentation per shipment rather than per supplier → You answer for the specific operation. --- --- id: KB-NO-023 url: https://app.codecontract.io/help/regulation/documents-that-carry-personal-data idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-013, KB-TZ-006] citadoPor: [KB-PR-025, KB-NO-027] --- # When the document you ask for carries personal data _You ask a company for a certificate and it arrives with names, ID numbers and payslips inside. From then on, that is yours to look after._ **Responde a:** can i ask for my supplier's workers id · subcontractor paperwork with personal data · how long do i keep third party data · what data can i require from a supplier You ask for «the subcontractor's paperwork» and a folder arrives with the worker list, their ID numbers, their contracts and sometimes their payslips. Nobody asked for it that way, but it is now inside. And what is inside is data about people who do not work for you and whom you have never asked anything. ## The three questions to ask before requesting | Question | If the answer is weak… | | --- | --- | | What do I need this for? | Do not ask for it. This filter avoids the most paper | | Would a version with less data do? | Ask for that one: it almost always exists | | How long do I need it? | If you cannot answer, it will stay forever | | Who in my company needs to see it? | «Everyone» is never the right answer | > [!IMPORTANT] > The practical rule that settles 90 % of cases: **ask for the proof, not the whole document**. To know someone is registered and covered you almost never need their payslip; to know a driver may drive that lorry you do not need their full medical history. Every extra piece of data entering your files is data you must protect, justify and one day delete — and that can be demanded back from you. **The paper you never ask for is the only one that never causes trouble.** ## What does need setting up 1. **State what you need it for, in the request itself** — One line. It is what turns a demand into a justified request. 2. **Give the document an expiry date** — Keeping things «just in case» is the decision nobody remembers taking. 3. **Restrict who can open it** — Sensitive material does not live in a folder shared with the whole office. 4. **And delete when due, recording that you did** — Deleting without a trace leaves you unable to show you complied. > [!WARNING] > The point most often missed: **whoever sends you the document cannot send whatever they like either**. If your request is so open that it nudges them into oversharing, you have created a problem for them and one for yourself. That is why a specific request —«the clearance certificate», not «the employment paperwork»— is not just convenience: it is how both sides end up holding only what is needed. And when too much arrives, the healthy move is to say so and ask for the reduced version, not to file it quietly. ## When someone asks for their data back **En corto** - It will happen: someone will ask what you hold about them, and it will not be your employee. - Answering quickly hinges on one thing: knowing which files it sits in and why. - And on having recorded who sent it and for what purpose, which is what justifies holding it. > [!NOTE] > What data may be required from a third party, on what basis and for how long it may be kept is data-protection territory and depends on context —a subcontractor on site is not the same as a service provider—. **Your adviser or DPO settles that**; here we cover the part that is genuinely yours: asking for less and knowing what you hold. **Can I ask for my supplier's workers' ID numbers?** It depends what for. Ask first whether a certificate from the supplier would do. **They sent more than I asked for — do I delete it?** Say so, ask for the reduced version and record it. Filing it quietly is the worst option. **Is a shared folder good enough?** Not for personal data. The question is not where it sits, it is who can open it. ## Ejemplos **You ask a subcontractor for «the employment paperwork» and it arrives with twelve people's payslips.** - Replaces the request with the specific certificate needed - Asks for the reduced version and records it → The file stops holding payslips of people who do not work for you. **Someone who worked for a subcontractor asks what data you hold about them.** - Searches their name across the files and answers with what is held and why → The reply goes out in hours because it is on record who sent each document and for what purpose. **A certificate containing personal data has sat for four years in a folder shared with the whole office.** - Restricts who can open it and sets a deletion date → Sensitive material stops being within reach of people who do not need it, and now has an expiry. **A certificate arrives with payslips inside and is filed as-is.** - Checks what it contains before storing it → You know what you are holding. **The whole team can open that folder.** - Limits who sees anything containing personal data → Access stops being general by default. **It is kept indefinitely just in case.** - Applies a retention period → What is kept has a reason and a period. --- --- id: KB-NO-024 url: https://app.codecontract.io/help/regulation/the-products-technical-file idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-015, KB-NO-007] citadoPor: [KB-NO-025, KB-AL-026, KB-IU-017, KB-IU-019] --- # The product's technical file _The declaration of conformity is the cover page. The technical file is what sits behind it, and it is what gets asked for when someone doubts._ **Responde a:** what is a product technical file · what documentation to keep for a product i make · asked for the technical file · how long to keep technical documentation A declaration of conformity fits on one page and is signed in a minute. That is why it gets signed cheerfully. What almost nobody looks at on signing day is the awkward question behind it: **and on what basis?** The set of answers to that question is the technical file. **Technical file** — The set of documents showing WHY the product complies: tests, calculations, drawings, standards applied and the risk assessment. It does not ship with the product; it is kept and produced on request. ## What it usually holds, and where it usually fails | Piece | Who holds it | Where it gets lost | | --- | --- | --- | | Laboratory test reports | The lab and you | Left in the inbox of whoever commissioned it | | Risk assessment | Whoever designed it | Never written down — it was «done mentally» | | Drawings for the version sold | Engineering | The new drawing exists; the sold version's does not | | Standards applied and their edition | Quality | The standard was cited without saying which year | | Documentation for bought-in components | Purchasing | Each supplier sends their own format and it scatters | > [!IMPORTANT] > The mistake that turns this into a serious problem is one of timing: **the file gets assembled when someone asks, and by then half of it is missing**. The lab closed, the engineer who did the calculations left, the component supplier changed hands. None of that is recoverable afterwards. A technical file is built the day the declaration is signed, not the day the question arrives — because on the day the question arrives you can no longer manufacture the past. ## Building it so it outlives the people 1. **One file per product and per version** — «The file for model X» without a version is the door to producing the wrong paper. 2. **Every document dated and attributed** — A test report with no date and no identifiable lab supports nothing. 3. **The edition of the standard, not just its number** — Standards get revised; citing the 2014 one when 2021 applied is a classic. 4. **And component documentation inside, not linked** — A link to the supplier's website expires when they redesign it. > [!WARNING] > One costly confusion, easily undone: **the instruction manual is not the technical file**. The manual travels with the product and is read by the customer; the file stays with you and is read by whoever investigates. Mixing them means over-delivering to customers —including calculations and supplier names you would rather not publish— and missing what actually matters when the question comes from an authority. ## And how long it is kept **En corto** - Measured from the last unit sold, not from the declaration date: two different clocks. - And for long-lived products —machinery, installations— far beyond the lifespan of any office computer. - Which is why the file does not live on anyone's laptop or in a folder that depends on who is still around. > [!NOTE] > Exactly what the file must contain, who may demand it and for how many years it must be kept depends on the product type and the rules applying to it. **Your adviser or notified body settles that**; here we explain why it is assembled on signing day and not on question day. **Do I have to hand the file to my customers?** Normally no: it is kept and shown to those entitled to ask for it. **Are my suppliers' certificates enough?** They are one part. The file explains your product, not only its pieces. **What if someone else manufactures for me?** Then agree in writing who keeps what, before you start selling. ## Ejemplos **An authority asks for the file on a product sold four years ago and the testing laboratory no longer exists.** - Keeps a copy of each test report in the file the day it arrives, not a link to the lab → The file stays complete even though the test provider has vanished. **The model X file is produced and turns out to be the current version's, not the unit sold.** - Opens one file per version and freezes each at launch → Every unit sold has the documentation that belongs to it behind it, not someone else's. **The engineer who ran the calculations has left and nobody can find the risk assessment.** - Requires the assessment to be written and filed before the declaration is signed → What lived in one person's head moves into the company's file. **The declaration is issued and there is no file behind it.** - Gathers what backs it into one file → The cover page has what supports it behind. **The file lives on the machine of whoever made it.** - Stores it off personal machines → Somebody leaving does not take the file. **The file is requested and a supplier's contribution is missing.** - Keeps third-party material with its own → The file is complete. --- --- id: KB-NO-025 url: https://app.codecontract.io/help/regulation/changing-a-component-in-a-certified-product idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-024, KB-IU-009, KB-NO-018] citadoPor: [KB-NO-015] --- # Changing a component in a certified product _A supplier discontinues a part, you buy the equivalent and carry on selling. The paperwork still describes the old one._ **Responde a:** changed a component do i need to recertify · equivalent part certified product · supplier discontinued a component · when to redo the declaration of conformity It happens in every company that makes something: a part stops being supplied, you buy the equivalent from the next catalogue and the line keeps running. Nobody did anything odd — it is the sensible call to avoid stopping. The problem shows up months later, when someone compares what is inside the product with what its papers say. ## The four kinds of change, from quiet to loud | Change | What it usually means | | --- | --- | | Same maker, same part number, different batch | Nothing: this is the normal case | | Same maker, successor part number | Check their data still covers your claims | | Different maker, «equivalent» part | This is where the real work starts | | A part touching safety, food contact or the electrical circuit | Stop and check before fitting a single unit | > [!IMPORTANT] > «Equivalent» is a purchasing word, not a quality one. **Two parts can be mechanically interchangeable and documentarily not**: same size, same function, and behind them a different certificate, a different material or a test run to another standard. The right question is never «does it fit?» but **«is what I declare about my product still true with this part inside?»**. The first is answered by the warehouse; the second by the technical file. ## What to do on the day of the change, not the day of the problem 1. **Ask the new supplier for the same documentation you held for the old one** — If they cannot provide it, that is already your answer. 2. **Compare it against what your product declares** — Standard applied, material, limit values. Point by point, not from memory. 3. **Record from which serial or batch the new part is fitted** — Without that boundary you cannot contain anything if a review is ever needed. 4. **And update the technical file before the first unit ships** — After that it becomes archaeology. > [!WARNING] > The scenario to avoid at all costs is the silent one: **the supplier makes the change and does not tell you**. Same part number, same delivery note, and inside a different material or a different factory. That is why the commitment to notify changes is requested IN WRITING when the supplier is onboarded and not once suspicions arise — and why it pays to keep each component's datasheet with its date: it is the only thing that lets you show what you were being supplied at any given time. ## When the change does force new paperwork **En corto** - If it affects what you declare, the declaration is redone: that is not a matter of opinion. - If the product had test reports, work out which need repeating — almost never all of them. - And if the product is already on the market, the decision stops being purely technical: who tells whom enters the room. > [!NOTE] > Which changes force repeat testing, a new declaration or notifying a body depends on the product and its regulatory framework. **Your adviser or notified body settles that before the part is fitted**; here we explain how not to arrive at that conversation with two hundred units already sold. **Can I fit an equivalent part while I check?** It depends what it touches. If safety is anywhere near, the prudent answer is no. **Does the whole product need recertifying?** Rarely. The norm is reviewing the affected part, and for that you need the file. **What if the supplier changed it without telling me?** Document from when, assess the impact, and revisit the notification agreement with them. ## Ejemplos **Purchasing swaps in an equivalent part from another maker to keep the line running.** - Asks the new supplier for the same datasheet and certificate held for the old one - Compares point by point against what the product declares → The change is decided on data rather than on «it fits the same». **Units already sold need reviewing and nobody knows since when the new part has been fitted.** - Records the serial or batch number from which each change applies → The review is contained to the affected units instead of a whole year's output. **A supplier changes factory without notice and you find out from a colour difference.** - Keeps each component's datasheet with its date and requires written change notification → You can show what was being supplied when, and claim against something written down. **A part is substituted and nobody touches the documentation.** - Reviews which documents describe that part → The papers keep describing what is made. **Nobody knows from which unit the component changed.** - Records from which batch the new part enters → You can say what each unit carried. **The new part's supplier provides no documentation.** - Requests it before starting to use it → The change does not leave a gap in the file. --- --- id: KB-NO-026 url: https://app.codecontract.io/help/regulation/the-waste-thats-been-in-the-yard-for-months idioma: en categoria: normativa subcategoria: residuos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-003, KB-NO-020] citadoPor: [KB-NO-012] --- # The waste that's been in the yard for months _Storing your own waste until collection is normal. What is not normal is that nobody knows since when it has been there._ **Responde a:** how long can i store waste on site · waste piling up at the company · temporary storage of waste · the waste manager is not collecting It starts with a pallet set aside «until the lorry comes». Then there are three. Then there is a corner of the yard everyone avoids looking at and nobody remembers when it filled up. There is no bad faith at any step: collection costs money, the lorry comes when there is volume, and volume takes time. ## Why the date matters, not just the place | What gets looked at | What is actually being asked | | --- | --- | | Where it is stored | Whether the place suits THAT waste | | How much there is | Whether the amount matches what you produce | | **Since when it has been there** | **The question almost nobody can answer** | | Where it goes | Whether the manager is authorised for that code | > [!IMPORTANT] > The third row decides how a visit ends: **if you cannot say since when each thing has been there, you cannot show you have not been accumulating for years**. And «the collector never came» only works if it is written down: phone calls leave no record, emails do. A two-column log —what entered temporary storage and what left, with dates— turns a suspicious corner into explained storage. ## What needs to be in place, and it is not much 1. **A visible date on each stored batch of waste** — A label with the day it started filling. It sounds trivial and it solves almost everything. 2. **The in-and-out log for temporary storage** — What, how much, since when and on which document it left. 3. **The removal paperwork, filed under the real date** — Not the date the lorry was requested: the date of removal. 4. **And an alert before you reach whatever limit you set yourself** — What does not warn you gets discovered full. > [!WARNING] > Two things make this much worse and are easy to avoid: **mixing** and **leaving it uncovered**. Hazardous waste among general waste drags the whole container into its category, and from there the problem is a different size. And storing outdoors what should not be turns controlled waste into a spill when it rains — which is no longer about deadlines but about soil and water. If the right place does not exist, that gets solved before generating more, not after. ## When the one not showing up is the collector **En corto** - Request collections in writing, even if you also call: what supports your position is the date of the request. - Keep their replies, including the ones that never come: a dated silence is evidence too. - And find an alternative before the yard decides for you. > [!NOTE] > How long each type of waste may be stored at the producer's premises, under what conditions and with what records is set by the waste rules, and it varies with type and quantity. **Your adviser settles that**; here we cover the part that is always yours: knowing since when each thing has been there and being able to show it. **How long can I store it?** It depends on type and quantity. What depends on nothing is having to know since when it has been there. **Is a dated photo enough?** It helps, but what is asked for is the log. The photo supports it; it is not it. **What if the waste came from works at my premises?** Then the first question is whose it is. That gets agreed before anyone comes in. ## Ejemplos **An inspection asks since when a batch has been stored and nobody on site knows.** - Labels each batch with the date it started filling - Keeps an in-and-out log → The corner of the yard goes from suspicious to explained, with dates. **The collector has not come for two months and temporary storage is at its limit.** - Requests collections in writing and keeps both the replies and the silences → The delay stops being yours: it is on record who asked, when, and what came back. **Tins of solvent turn up in the general waste container.** - Separates before storing and trains whoever throws away, not only whoever manages → A whole container stops changing category over four tins. **The waste has sat in the yard for months and nobody knows since when.** - Records the generation date when it is set aside → Elapsed time is a fact rather than an impression. **Several consignments pile up in the same place.** - Records each with its date → The oldest is identified without opening anything. **Nobody flags that it needs removing.** - Lets it warn when it has sat too long → Collection is requested before it becomes a problem. --- --- id: KB-NO-027 url: https://app.codecontract.io/help/regulation/asked-for-information-i-dont-want-to-share idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-023, KB-PR-028] citadoPor: [KB-NO-014] --- # They ask for information I don't want to share _Saying so is legitimate, and there is usually a middle path: most of the time they need proof, not the whole document._ **Responde a:** asked for confidential company information · can i refuse to give a client information · they want my purchase prices · how far can i refuse to share paperwork **You can say no, and saying it well does not damage the relationship.** What damages it is silence, or an «I'll send it» that never arrives. And before reaching a flat no, there is nearly always a middle path that serves them just as well. ## What they actually need, nearly always | They ask for | What usually suffices | | --- | --- | | Your whole contract with your supplier | A letter from them confirming the point at issue | | Your costings or purchase prices | A declaration of origin or composition | | Your staff's details | A certificate from your company, without the names | | Your internal procedures | The index, or the specific section that affects them | > [!IMPORTANT] > **The sentence that opens almost every door is «what do you need to be able to demonstrate?».** Requesters have usually copied the list from elsewhere and never asked themselves whether they need the whole document or just the fact inside it. The moment they phrase it, the reduced version appears — and that version leaves you comfortable while serving them exactly as well. ## How to say no without slamming a door 1. **Say which part you can, in the same sentence** — «Not the contract, but yes a letter confirming X». 2. **Give the reason in one line** — «It contains third-party prices» lands; «company policy» says nothing. 3. **Offer the alternative yourself** — Whoever proposes the way out is the one who defines it. 4. **And put it in writing** — So that a year from now, what was asked and agreed is on record. > [!WARNING] > There is one case where refusing is not merely legitimate but correct: **when what they want contains data about people or about a third party who has not consented**. There the issue is not your confidentiality, it is that it is not yours to hand out. The way out is the same —a certificate evidencing the fact without the data— and it is worth saying why, because requesters often had not realised what they were asking for. > [!NOTE] > What information may be required within a contractual relationship, what a confidentiality agreement protects, and what limits data protection imposes when the document concerns third parties depends on the contract and the case. **Your adviser settles that**; here we explain how to reach that conversation with an alternative on the table rather than a refusal. **Can I refuse without giving a reason?** You can, but one line of reason changes how it is received. **What if they insist?** Ask them what they need to demonstrate. It usually unblocks. **Does signing an NDA help?** Sometimes yes, and proposing one shows you are not hiding. ## Ejemplos **A client asks for your full contract with your supplier, which contains third-party prices.** - Offers a letter from the supplier confirming the specific point that concerns the client → The client gets what they need to demonstrate and the prices stay inside your company. **You are asked for the staff list with their personal details.** - Proposes a company certificate evidencing the fact without the names → The requirement is met without handing out data on people who never agreed to it. **The whole document is sent when part would have done.** - Asks what exactly they need to verify → You deliver what addresses their need. **It is refused with no alternative offered.** - Offers the equivalent proof that can be given → The conversation moves instead of stalling. **The document contains third-party data.** - Says so and proposes a version without it → What was not yours to give is protected. **It is handed over under pressure and cannot be taken back.** - Decides before sending, not during the call → The decision is not taken under pressure. --- --- id: KB-NO-028 url: https://app.codecontract.io/help/regulation/the-insurance-they-want-and-the-one-you-have idioma: en categoria: normativa subcategoria: cadena audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-018, KB-NO-017] citadoPor: [KB-NO-022] --- # The insurance they want and the one you have _Holding a policy and being covered for that job are not the same thing. The gap only shows once something happens._ **Responde a:** asked for a certificate of insurance · does my policy cover this job · public liability insurance clients ask for · asked for a higher cover limit A new client sends their documentation list and there it is: a certificate of insurance with a specific limit and specific covers. It gets forwarded to the broker, the certificate arrives, it is uploaded and forgotten. That is where the problem slips in, because nobody compared what was asked for against what the policy says. ## The four gaps a certificate does not show | What they ask for | What to check | | --- | --- | | A minimum limit | Whether it is per claim or per year: not the same | | A specific cover | Whether your actual activity falls inside what is insured | | That it is current | The date, and that the premium is paid | | That it names them | That sometimes needs an endorsement, not just a certificate | > [!IMPORTANT] > **The certificate says you hold a policy; it does not say that job is covered.** Two different claims, and only the first is evidenced by a one-page document. What decides on the day of a claim is the declared activity: if you started out installing and now also do maintenance, or you have moved into a type of work that is new for you, the policy may well be current and not cover what you are doing. ## What to review, and when 1. **Compare the declared activity against what you do today** — The check that avoids most grief, and it takes one session a year. 2. **Look at the limit and on what terms it stands** — Per claim, per annum, with an excess: it changes a lot. 3. **Tell the broker when your work changes** — A new client from another sector is reason enough. 4. **And file the certificate with its expiry and an alert** — It lapses yearly, and always at a bad moment. > [!WARNING] > The case that most often ends badly: **they ask for a higher limit than you hold and you upload it anyway, hoping nobody looks**. Almost nobody does — until there is a claim, and then everybody looks at once. Saying so beforehand is awkward for a day; not saying it can leave you outside cover and in breach of contract simultaneously. And raising a limit usually costs considerably less than people imagine. > [!NOTE] > What cover each type of contract requires, what the limits mean exactly, and what is needed for a third party to appear on the policy is determined by the contract and by your insurer's terms. **Your broker settles that before the work is signed**; here we explain what to compare so you do not find out on the day of a claim. **Is the certificate from my insurer enough?** To evidence a policy exists, yes. To know whether it covers THAT job, read the terms. **They want a higher limit than I hold** Discuss it with your broker before signing. It usually costs less than expected. **How often should I review it?** Yearly, and whenever what you actually do changes. ## Ejemplos **An installer starts doing maintenance too, and the policy declares installation only.** - Tells the broker about the change of activity before signing the first contract → The cover describes what the company actually does, not what it did three years ago. **A client asks for a higher limit than is held and the certificate is uploaded regardless.** - Raises it with the broker and with the client before signing → Being simultaneously outside cover and in breach of contract is avoided. **The certificate lapses yearly and is always discovered when a client demands it.** - Files it with its expiry date and an advance alert → The renewal is requested in good time rather than in a rush. **The policy is sent without checking what it covers.** - Checks it covers that work before sending it → Discovering the gap when something happens is avoided. **The client asks for a limit above what is contracted.** - Discusses it with the broker before accepting the contract → The commitment matches the real cover. **The policy expires midway through a long job.** - Records the expiry when filing it → Renewal happens before it bites. --- --- id: KB-NO-029 url: https://app.codecontract.io/help/regulation/the-certificate-is-signed-by-someone-nobody-knows idioma: en categoria: normativa subcategoria: producto audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-015, KB-NO-022] citadoPor: [KB-IU-018] --- # The certificate is signed by someone nobody knows _A certificate is worth whatever its issuer is worth. Checking takes three minutes and almost nobody spends them._ **Responde a:** how do i know a certificate is valid · certificate from an unknown laboratory · check whether a certifier is accredited · fake supplier certificate A certificate arrives with a stamp, a reference number and an impeccable look. It gets filed. Months later someone asks who issued it and it turns out to be a body nobody has heard of, appearing in no register, whose website runs to three pages. The document is not fake — it simply evidences nothing. ## The four grades, and only the first is fraud | What it is | What it is worth | | --- | --- | | A forged document | Nothing, and it is a serious problem besides | | Genuine, from an unrecognised body | Little: it is one company's opinion | | Genuine, but of another scope | Good for its own scope, not for yours | | Genuine, recognised and current | What you were after | > [!IMPORTANT] > **The row that shows up most in real life is the second, and it is not fraud: it is marketing.** One company pays another to review something and receives a document saying so. All true, all genuine, and worthless to whoever requires accreditation of you — because what is required is not that somebody certifies it, but that it is certified by whoever is recognised to do so. Telling those apart is exactly the work nobody does at filing time. ## Three checks, three minutes 1. **Search for the issuer by name and number** — Recognised bodies appear in public, searchable registers. 2. **Read the certificate's scope, not just its title** — It is usually in the small print, and that is where cover shows. 3. **And check the date and the status** — A suspended or withdrawn certificate looks exactly the same. > [!WARNING] > One detail separates those who check from those who file: **the certificate you need is the one for the specific product or process, not for the company**. A manufacturer holding a management certification says nothing about whether THAT model meets what you need. It is the most commercially exploited confusion and the easiest to undo: look for what you are buying inside the certificate. > [!NOTE] > Which accreditation is required in each case, which bodies are recognised to issue it and how currency is verified depends on the product, the sector and the country. **Your adviser or the relevant body settles that**; here we explain how to spot the case where a genuine document evidences less than it appears to. **Is a stamped certificate valid?** The stamp is not the evidence. The issuer and the scope are. **Can I ask the supplier to justify it?** Yes, and an evasive answer is itself information. **What if the issuer is in no register?** Treat it as a supplier declaration, which is a different thing. ## Ejemplos **A supplier hands over a certificate from a body that appears in no register.** - Looks the issuer up before filing and treats it as a supplier declaration → The file reflects what that paper actually evidences, which is less than it seemed. **The manufacturer's management certification is filed in the belief it covers the product.** - Checks whether the model being bought appears in the certificate's scope → It emerges in time that the product document was missing, not the company one. **A valid-looking certificate has been withdrawn for months and the paper looks just as impeccable.** - Checks the status and currency, not only the printed date → The file stops resting on a document that is no longer in force. **A certificate arrives and is filed without looking at who issued it.** - Checks the issuer before accepting it → A certificate is worth what its signatory is worth. **The issuer cannot be found anywhere.** - Asks the supplier and records the answer → The doubt is settled before a client settles it. **A client asks about the issuer of one of your certificates.** - Checks what was recorded on receipt → You answer without phoning the supplier. --- --- id: KB-CS-002 url: https://app.codecontract.io/help/food-and-beverage/food-supplier-certificates idioma: en categoria: sector-alimentacion subcategoria: distribucion audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-CS-001, KB-TL-001, KB-SC-001] citadoPor: [KB-CR-001, KB-CS-003, KB-CS-005, KB-CS-006] enLaApp: https://app.codecontract.io/trackline/schemas --- # Supplier certificates in the food sector _Collect data sheets, allergen info and certifications from every supplier, with expiry alerts._ **Responde a:** how to collect certificates from food suppliers · supplier document control IFS BRC · managing technical data sheets and allergens · documentation for a food safety audit · expired supplier certificates A food business with seventy product lines holds, for every supplier, a technical data sheet, an allergen declaration, a certificate for whichever standard applies and often a certificate of origin. That is hundreds of documents with different review dates, and the auditor asks for all of them on the same day. **En corto** - One process per supplier type, run at onboarding and at every renewal. - Automatic reading pulls the validity date and certificate number out of the document. - The expiry alert fires before it lapses, not when the auditor spots it. - The audit dossier is exported in one go, with no manual gathering. ## What to ask a food supplier for | Document | How often | Why it is asked for | | --- | --- | --- | | Product technical data sheet | At onboarding and on every reformulation | It is the basis of your own sheet and of the label | | Allergen declaration | At onboarding and on every change | Direct liability: an undeclared allergen is a serious incident | | Standard certification (IFS, BRC, ISO 22000) | Annually | Your own audit asks for it, not just your client | | Certificate of origin or health certificate | Per batch or per season | Mandatory on imports and for some products | | Food business registration | At onboarding | Without it the supplier should not be approved at all | ## The real problem is not asking: it is expiry Almost everyone manages to gather the paperwork at onboarding. What fails is year two: the supplier's IFS certificate expired in March, nobody looked, and the finding turns up in the October audit. With an expiry date on the document, the alert fires on its own and the renewal is requested before there is a gap. > [!NOTE] > If automatic reading pulls the validity date off the certificate itself, nobody has to type it in — which is exactly where the error creeps in that nobody later spots. ## What the auditor takes away In a food safety audit what counts is not only holding the document: it is demonstrating there was a system. One file per supplier, with the date each document was requested, the date it arrived and the renewal alert on record, answers that question better than a folder full of PDFs. ## Frequently asked questions **Can I ask for different documents by supplier type?** Yes: one process per type. A raw material supplier is not asked the same things as a packaging supplier or a haulier. **How do I keep allergens under control when a formulation changes?** The allergen declaration is requested at onboarding and on every change. Because each is dated, you can see which version was current when each batch was produced. **Does it help prepare an IFS or BRC audit?** That is one of the main uses. You export the dossier with the evidence and its dates, instead of compiling for days. **What about temperature or cleaning records?** Those are not requested from anyone: you generate them. They fit better as certified evidence, so they carry a demonstrable date. ## Ejemplos **A manufacturer is audited to IFS and is asked for the current certificate of twelve raw material suppliers.** - Filters the raw material supplier files - Confirms none has an expired certificate, because the alerts fired when they were due - Exports the dossier with the twelve pieces of evidence and their dates → It is handed over on the spot, and the auditor can independently verify the date of every document. **A technical sheet expires and nobody notices until the audit.** - Records each document's validity on receipt → The warning arrives before the auditor. **Each supplier sends the sheet in a different format.** - Requests specific documents to a single destination → What is received can be compared. **An allergen changes and nobody reviews the labels.** - Asks the supplier to communicate any change → The change arrives before the problem. **Chasing sixty suppliers takes a morning a week.** - Requests and chases automatically → The morning is recovered and the sheets still arrive. **An audit asks you to evidence ten suppliers.** - Checks each one's file → The handover is prepared in minutes. --- --- id: KB-CS-018 url: https://app.codecontract.io/help/food-and-beverage/food-manufacturing-and-packaging idioma: en categoria: sector-alimentacion subcategoria: distribucion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-007, KB-NO-002] citadoPor: [KB-CS-019, KB-CS-025] --- # Food manufacturing and packaging _Raw materials, packaging and customer audits in one case file._ **Responde a:** raw material supplier documentation · food safety technical data sheets · ifs brc audit documentation · food contact materials Food manufacturing carries three documentary demands usually handled separately that are really one case file: food safety, packaging, and whatever the customer asks for when they are a large chain. ## The three modules, by block | Block | Module | What moves | | --- | --- | --- | | Supplier approval | Trackline | Technical sheets, health certificates, allergen declarations | | Food contact materials | Trackline | Packaging declaration of conformity, per reference | | Quality agreements with suppliers | Consigne | Specifications signed, not merely agreed by email | | Process and control records | SmartCheck | Certifying the periodic register, with a third-party date | > [!IMPORTANT] > The packaging declaration of conformity is held by your supplier and the duty to hold it is usually yours. It is the document most asked for in customer audits and the one most often missing, because nobody requested it when the packaging was approved. ## Frameworks cited Food hygiene and self-control systems, food traceability, consumer information and allergens, food contact materials, and the private certification schemes retailers require. What applies to your activity and to what extent is confirmed by your adviser or certification body. > [!WARNING] > Health certificates and approvals expire. A supplier who was approved when you bought and stopped being so three months later is exactly what surfaces in a recall, with dates attached. > [!NOTE] > If a large customer audits you annually, build their questionnaire as a process. What they ask changes little, and the second time costs an afternoon instead of a week. **Can it be queried by batch?** If the batch is linked to the supplier's case, yes, and that is what narrows a recall. **What about my suppliers' suppliers?** Requested inside your direct supplier's case, as further documentation. **Does it help with an unannounced audit?** That is where it shows most: you show it, you do not search for it. ## Ejemplos **A packer is audited by a customer and asked for conformity declarations on twelve packaging references.** - Finds four; the other eight were never requested - Requests them from packaging suppliers and marks them with expiry → The next audit is answered by showing, and the declarations renew themselves annually. **A client audit arrives with two weeks' notice.** - Checks what is missing per supplier before it lands → The gaps close with time to spare. **Packaging documentation sits apart from raw materials.** - Gathers everything in the product's file → There is one picture of the product. **An ingredient changes and the labels stay the same.** - Reviews the affected references when the change arrives → The label keeps telling the truth. **A client asks for the traceability of a specific batch.** - Checks that batch's file → You answer per batch rather than per catalogue. **Every audit is prepared from scratch.** - Keeps the file current through the year → The second audit costs a fraction. --- --- id: KB-CS-019 url: https://app.codecontract.io/help/food-and-beverage/food-distribution-and-hospitality idioma: en categoria: sector-alimentacion subcategoria: distribucion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-018, KB-CS-008, KB-AL-020, KB-LG-026] citadoPor: [KB-CS-028, KB-AL-003, KB-AL-012] --- # Food distribution and hospitality _Many small suppliers, high staff turnover, and an inspection that can arrive any day._ **Responde a:** restaurant supplier documentation · food handler training records · health inspection what documents · food distributor traceability Here the problem is not documentary volume per supplier — usually little — but the number of suppliers and staff turnover. A restaurant with thirty suppliers and fifteen new hires a year cannot run this from a folder. ## What gets controlled, and with what | What | Module | Frequency | | --- | --- | --- | | Health registration and data sheets per supplier | Trackline | At onboarding and annual renewal | | Food handler training per person | Trackline | At onboarding, and it expires | | Staff contracts and amendments | Consigne | With every hire | | Temperature and control records | SmartCheck | Periodic certification of the register | > [!IMPORTANT] > Food handler training attaches to the person, not the role. With this sector's turnover it is the control that fails most: someone starts on Friday and works three weeks with nobody checking. Marking it as blocking at onboarding is what prevents it. ## Frameworks cited Food hygiene and self-control systems, food handler training, allergen information for consumers, and traceability upstream and downstream. Specific requirements vary by region and establishment type; confirm with your adviser or the relevant health authority. > [!WARNING] > At an inspection, what counts is not only holding the paperwork: it is being able to show it there and then. A perfect archive in an office twenty kilometres away is no use when the inspector is in the kitchen. > [!NOTE] > With many small suppliers the channel matters: plenty do not read email. SMS is what turns a two-week request into a two-day one. **Can I check it from a phone on the premises?** Yes, and that is precisely the use case: showing on the spot. **What about very small suppliers with nothing?** The case at least proves it was requested, with dates. **Does it work across several sites?** One team per site, with staff documentation kept separate. ## Ejemplos **A six-restaurant chain does not know which staff have current training.** - One case per person with training marked as blocking - 60-day warning → The manager checks from a phone before putting anyone on a shift. **A small supplier never sends their documentation.** - Asks for little, with an easy place to upload it → Response rates rise without more chasing. **New staff arrive every season.** - Checks per person what is missing before they start → Onboarding is not discovered incomplete on day one. **An inspection turns up unannounced.** - Keeps the file accessible from a phone → It is shown there and then rather than the next day. **Each site keeps its own papers separately.** - Gathers documentation in one place → The answer does not depend on which site is asked. **A supplier changes and nobody reviews their documentation.** - Launches the onboarding process on the first order → No supplier gets in without a file. --- --- id: KB-CS-025 url: https://app.codecontract.io/help/food-and-beverage/farms-and-livestock-holdings idioma: en categoria: sector-alimentacion subcategoria: agricultura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-018, KB-NO-004] citadoPor: [KB-AL-005, KB-AL-008, KB-AL-010, KB-CS-036, KB-AL-022] --- # Farms and livestock holdings _Field records, treatments and seasons: lots of temporary staff and one inspection a year._ **Responde a:** digital field record · seasonal worker documentation · plant protection treatment records · farm certification documentation A farm concentrates its paperwork in two moments: the season, when many people arrive at once and briefly, and the audit or inspection, when you have to show what was done all year. ## The three modules | What | Module | When | | --- | --- | --- | | Onboarding seasonal workers | Trackline + Consigne | In days, for many people at once | | Input supplier documentation | Trackline | At onboarding and renewal | | Treatment and field operation records | SmartCheck | Periodic certification of the record book | > [!IMPORTANT] > The farm record book is the document asked for at inspection and at certification audits, and its value depends on it not having been filled in after the fact. Certifying it periodically — at each month or season close — is what turns it into a record that cannot be argued with. ## What makes the season hard **En corto** - Many people, very little time, often without a work email. - Training and medicals needed before starting, not after. - Contracts signed the same day people arrive. This is where SMS stops being an extra: many of those workers do not read email, and an email request goes unopened until the season ends. ## Frameworks cited Primary production hygiene and traceability, plant protection product use and its records, seasonal labour conditions, and the farm certification schemes retailers require. What applies to your crop and region is confirmed by your adviser or certification body. > [!WARNING] > Applicator licences and training expire, and belong to the person. With seasonal turnover it is where control fails most: someone starts on Monday and applies a treatment on Tuesday with nobody having checked. > [!NOTE] > Saving the seasonal onboarding as a template turns the next one into hours. The list changes, the process does not. **Can forty people be onboarded at once?** Yes, as a batch send with the list. **What about people without a phone or email?** A paper remainder will persist; the aim is to shrink it. **Does it serve for a certification audit?** It is what gets shown: dated records that were not filled in afterwards. ## Ejemplos **A farm takes on 60 seasonal workers in a week and signs contracts on paper the same day.** - Sends contracts and paperwork as a batch, with SMS - Marks training and medicals as blocking → Nobody starts without current mandatory items, and onboarding drops from a week to two days. **The field record is filled in at season end from memory.** - Records at the moment, from a phone → The data is exact rather than reconstructed. **Temporary staff arrive every season.** - Checks per person what is missing before they start → Onboarding is resolved before day one. **A client asks about a consignment from months ago.** - Checks what was recorded on that date → There is an answer instead of an estimate. **Treatments are noted on paper that gets wet.** - Captures the note at the moment → The record outlives the field. **The annual inspection arrives and half the season is missing.** - Reviews the file before it lands → The gaps close with time to spare. --- --- id: KB-AL-001 url: https://app.codecontract.io/help/food-and-beverage/meat-industry idioma: en categoria: sector-alimentacion subcategoria: carnica audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-007, KB-AL-002] citadoPor: [KB-AL-002, KB-AL-003, KB-AL-004, KB-AL-010, KB-AL-024] --- # Meat industry _Traceability back to the farm of origin, and documented animal welfare._ **Responde a:** meat traceability to origin · abattoir and cutting plant documentation · animal welfare records · livestock supplier approval In meat, traceability does not stop at your supplier: it reaches the farm of origin. And the question that decides a recall is always in the past tense — which farm did this batch come from, and what did that farm hold on that day. ## The three modules | What | Module | When | | --- | --- | --- | | Farm and supplier approval | Trackline | At onboarding, with expiries | | Supply agreements and specifications | Consigne | Signed, not agreed by email | | Process and self-control records | SmartCheck | Periodic certification | > [!IMPORTANT] > What a recall asks for is the status on the batch date, not today's. A supplier approved now who was not when they supplied you is exactly what surfaces, and it only shows if the history keeps the versions with their dates. ## Frameworks cited Hygiene of products of animal origin and establishment approval, animal identification and registration, animal welfare on farm and in transport, and consumer information on origin. The exact scope depends on your activity and competent authority; confirm with your adviser. > [!WARNING] > Animal welfare and transport documents usually sit with third parties — the haulier, the farm — and are the slowest to arrive. Requesting them at approval rather than when a customer asks is the difference. > [!NOTE] > If retail chains audit you, their questionnaire changes little between editions: built as a process, the second audit costs an afternoon. **Can it be queried by batch?** If the batch is linked to the supplier's case, yes. **What about livestock hauliers?** Their own case, with authorisation and expiries. **Does it help with an unannounced inspection?** That is where it shows: you show it rather than search for it. ## Ejemplos **A cutting plant receives an alert and must scope which batches came from one farm.** - Checks that farm's history with its dates → Narrows it to two weeks of intake instead of a quarter. **A client asks for the traceability of one specific box.** - Checks the cutting batch's file → You reach the intake without reconstructing anything. **Welfare documentation arrives on paper with the consignment.** - Captures it when the animal is received → The paper stops being the only copy. **Carcasses from several origins are mixed in the same shift.** - Records what went into each output batch → You can say what came from where. **A holding's certificate expires.** - Records validity on receipt → The warning arrives before the next intake. **Customers of a specific batch must be warned.** - Checks which boxes came out of that batch → Those affected are warned rather than everyone. --- --- id: KB-AL-002 url: https://app.codecontract.io/help/food-and-beverage/wineries-and-beverages idioma: en categoria: sector-alimentacion subcategoria: bebidas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-001, KB-NO-002] citadoPor: [KB-AL-001] --- # Wineries and beverages _Designations, export and labelling: documentation that travels with the product._ **Responde a:** documentation to export wine · designation of origin documentation · beverage labelling requirements · food export certificates A winery has a documentary problem the wider food industry does not: much of its paperwork travels with the product to another country, where it is reviewed by someone with their own criteria and in their own language. ## The three modules | What | Module | Why | | --- | --- | --- | | Grape, packaging and ancillary suppliers | Trackline | Composition and packaging conformity | | Agreements with distributors and importers | Consigne | Signed before the first shipment | | Documentation for each shipment | SmartCheck | Certify what was sent, with its date | > [!IMPORTANT] > Export documentation is prepared per shipment and reviewed abroad. A document rejected at destination can leave goods stranded in customs at a daily cost, so the draft is checked before sending, not after. ## Frameworks cited Designation of origin and geographical indication rules, labelling and consumer information, oenological practices where applicable, and the destination country's requirements, which can differ considerably from European ones. What each market requires is confirmed by your adviser or regulatory council. > [!WARNING] > If you work under a designation of origin, the regulatory council's documentation has its own deadlines and renewals. It does not fit the rest of the calendar, which is why it gets forgotten. > [!NOTE] > When you always export to the same markets, the shipment is nearly identical. Built as a process, the twentieth costs a fraction of the first. **Can I have one process per destination country?** Yes, and you usually need to: markets do not ask the same things. **What about labels in other languages?** They go in as shipment documentation, with their version and date. **Does it serve for a regulatory council inspection?** It is what gets shown, with dates you did not set. ## Ejemplos **A winery has a shipment stuck in customs over a badly prepared document.** - Builds a process per destination market - Reviews the draft before sending → Later shipments clear first time and the cost of stranded days disappears. **Export documentation is prepared shipment by shipment.** - Gathers what repeats into a file → The second shipment to the same destination costs half. **Each market asks for different labels.** - Stores each version against its market → You know what was sold with which label. **A client asks you to evidence a specific vintage.** - Checks that vintage's file → You answer per vintage rather than per winery. **Designation documentation expires without warning.** - Records validity when filing it → Renewal happens with time to spare. **The packaging supplier changes and labels stay the same.** - Reviews what is affected when suppliers change → The label stays true. --- --- id: KB-AL-003 url: https://app.codecontract.io/help/food-and-beverage/supermarkets-and-supplier-approval idioma: en categoria: sector-alimentacion subcategoria: retail audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-001, KB-CS-019] citadoPor: [KB-AL-027] --- # Supermarkets: approving hundreds of suppliers _The requesting side, when what you ask for is asked a thousand times a year._ **Responde a:** supermarket supplier approval · auditing food suppliers · controlling documentation for a thousand suppliers · product recall scoping by supplier A retail chain sits on the opposite side from almost everything written so far: nobody asks it for documentation, it asks — of hundreds or thousands of suppliers, with its own audits and an obligation to scope a recall within hours. ## What changes at that volume **En corto** - One process per product family, not one per supplier. - Approval has to recalculate itself when something expires. - What cannot be seen in a filterable list will not be looked at. | What | Module | Typical volume | | --- | --- | --- | | Supplier approval and renewal | Trackline | Hundreds a year | | Commercial and quality agreements | Consigne | One per supplier, with amendments | | Own audits of suppliers | Trackline | Recurring, as a process | > [!IMPORTANT] > In a recall, the time goes on working out which suppliers and batches are affected. If approval is held per supplier and the history keeps the dates, that is a query; if it is in folders, it is a full day — and the hours count. ## Frameworks cited Food hygiene and traceability, the responsibility of the operator placing the product on the market, consumer information, and the private certification schemes retail itself requires of suppliers. Your specific obligations as an operator are confirmed by your adviser. > [!WARNING] > Demanding the same documentation from a small supplier as from a large one without adjusting the process ends with the small one not delivering. Distinguish by family and by risk rather than applying the maximum to everyone. > [!NOTE] > A 60-day expiry warning across hundreds of suppliers turns renewal into a manageable trickle instead of an annual campaign. **Can criteria differ by product family?** Yes, and they should: fresh and packaged are not asked the same. **Can an external auditor be given access?** Yes, scoped and for the engagement's duration. **How do I scope a recall?** By supplier and date, looking at the status held then. ## Ejemplos **A chain with 800 suppliers takes a full day to scope which held an affected ingredient.** - Per-supplier approval with dated history - Filtering by product family → The next alert is scoped in an hour, and the recall touches nine suppliers instead of the whole family. **A thousand onboardings a year are handled by email.** - Launches the same process to all → Onboarding stops being craft work. **Each buyer asks the same supplier for different documents.** - Shares a single template → The supplier receives a coherent request. **Nobody knows which suppliers are current.** - Checks the status of all at once → You act on the failing ones. **A supplier delivers and their document expires two months later.** - Records validity on approval → The warning arrives before the next order. **Chasing the stragglers occupies several people.** - Lets the reminders go out on their own → The team reviews instead of nagging. --- --- id: KB-AL-004 url: https://app.codecontract.io/help/food-and-beverage/use-cases-in-dairy idioma: en categoria: sector-alimentacion subcategoria: lacteos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-001, KB-AL-005] citadoPor: [KB-AL-005, KB-AL-006, KB-AL-025] --- # Twenty-one real cases in dairy _Concrete day-to-day situations in a dairy business, and what solves each one._ **Responde a:** dairy industry use cases · milk supplier document control · raw milk traceability · dairy customer audit documentation A dairy business collects from dozens of farms, processes on short timescales and sells to chains that audit. These are the cases that actually come up, ordered by what each one solves. ## Requesting and controlling documents | The situation | What you build | | --- | --- | | Onboarding a new farm without knowing what to ask for | An onboarding process with the mandatory items in phase one | | Farm health certificates expire and nobody keeps count | Expiry marked, 60-day warning | | A vet asks for one holding's records | One case per farm, with its dated history | | 40 farms' documents have to be renewed every January | One batch launch, with automatic reminders | | The raw milk haulier changes and nobody checks their authorisation | The haulier's own case, with expiries | | A customer asks for yoghurt packaging conformity | A request to packaging suppliers, stored per reference | | External laboratory results get lost in email | They go into the batch's case, with their date | ## Signing | The situation | What you build | | --- | --- | | The supply agreement with a farm is closed verbally | Contract signed before the first collection | | Prices have to be updated with 40 farms at once | One amendment, one batch send, tracking who is missing | | Hauliers sign terms on paper and they get lost | Signed from a phone, with their copy | | A distributor asks for a signed quality agreement | Specifications signed, not agreed by email | | Plant staff onboarding in peak season | Contract signed before day one | | A customer requires an NDA before an audit | Signed same day, with no travel | | A supplying farm changes ownership | Novation signed by all three parties, in order | ## Certifying and proving | The situation | What you build | | --- | --- | | Tank temperature records are an editable file | Periodic certification of the register | | A claim about a batch from eight months ago | That batch's process record, with a trusted date | | A farm disputes an analysis result | The result certified on the day it was issued | | The condition of a tanker at intake has to be shown | Certified photos at unloading | | An auditor asks whether self-controls were filled in afterwards | Monthly certification of the register | | A cold chain incident in distribution | Journey record certified at close | | Proof of when a non-conformity was communicated to a supplier | The communication certified the same day | > [!WARNING] > Of the twenty-one, the one that most often prevents a serious problem is the penultimate: the cold chain breaks at loading or unloading, not on the road, and that is where to document. > [!NOTE] > You do not have to build them all. Farm onboarding plus expiry dates already covers half the repetitive work; the rest gets added when the need appears. **Where do I start if I only do one?** Farm onboarding: it repeats most and moves the most paper. **What if my farms are small and do not use email?** SMS is what changes delivery in this sector. **Does it serve for a customer audit?** All three blocks are exactly what one asks for. ## Ejemplos **A dairy with 38 farms spends all of January renewing documentation.** - Builds onboarding as a process - Launches renewal as a batch with reminders - Marks health certificates with a 60-day warning → January stops being a campaign: renewal becomes a trickle with four phone calls. **Milk from several farms shares a tank and the prior record is missing.** - Records what went in before mixing → The trace survives the blend. **A client asks about a batch from three months ago.** - Checks that batch's file → You answer without reconstructing. **Analyses arrive by email and are filed loose.** - Attaches them to the batch on receipt → The analysis lives with what it analyses. **A farm certificate expires mid-season.** - Records its validity on receipt → The warning arrives before collection. **An incident must be contained and the batch spans a whole day.** - Defines narrower batches where it pays → Scope narrows to what is actually affected. --- --- id: KB-AL-005 url: https://app.codecontract.io/help/food-and-beverage/use-cases-in-fruit-and-vegetables idioma: en categoria: sector-alimentacion subcategoria: frutas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-004, KB-CS-025] citadoPor: [KB-AL-004, KB-AL-022] --- # Twenty-one real cases in fruit and vegetables _Season, export and auditing chains: what actually comes up in a fruit and vegetable business._ **Responde a:** fruit and vegetable use cases · seasonal farm documentation · fruit export documentation · farm certification audit documentation A fruit and vegetable business concentrates everything into the season: many people arrive, many growers deliver and a lot of product leaves, often abroad. These are the cases that repeat every year. ## Requesting and controlling documents | The situation | What you build | | --- | --- | | Onboarding 60 seasonal workers in a week | Batch onboarding, with SMS and blocking mandatory items | | Applicator licences expire and belong to the person | Per-person expiry, 60-day warning | | New growers have to be approved each season | A reusable onboarding process; only the list changes | | A customer asks for growers' farm certification | Certificates requested and stored with their expiry | | Intake delivery notes get lost | They go into the grower's case, with dates | | A new refrigerated haulier arrives unchecked | The haulier's case, checkable at the bay | | Outdated plant protection product sheets | An annual request to input suppliers | ## Signing | The situation | What you build | | --- | --- | | Seasonal contracts signed on paper on day one | Signed before starting, from a phone | | Grower agreements closed verbally | Season contract signed before the first delivery | | A foreign importer asks for a signed agreement | Signed with a phone code, no travel | | Image consent for farm photography | Signed consent, withdrawable | | Quality terms with a distributor | Specifications signed by both parties | | Mid-season price amendment | One batch send to every grower | | Sign-off on receipt of a large order | Signed by the recipient, on the spot | ## Certifying and proving | The situation | What you build | | --- | --- | | The field record book is filled in at season end | Monthly certification of the register | | A claim about product arriving in poor condition | Certified photos at loading | | A dispute with a grower about what was delivered | Intake record certified that day | | Proving the temperature of an export container | Journey record certified at close | | An auditor questions a treatment date | Treatment register certified periodically | | Evidencing the condition of a rejected consignment | Photos and report certified at the moment of rejection | | A shipment held at customs over documentation | What was submitted, certified with its date | > [!WARNING] > A field record book filled in at season end is the commonest audit finding and the hardest to defend. Certifying it monthly costs minutes and completely changes how it reads. > [!NOTE] > There is no time to build anything during the season. What you build in February is what works in July. **Can 60 people be onboarded at once?** Yes, with the list and a batch send. **What about growers who do not use email?** SMS. In this sector it decides delivery. **Does it serve for a farm certification audit?** Records with trusted dates are exactly what is asked for. ## Ejemplos **A packhouse prepares the season in June and sets up seasonal onboarding two days before it starts.** - Builds the process in February - Tests on five people before the season → In July the 60 onboardings take two days instead of two weeks, and nobody starts without the mandatory items. **The season starts and nobody knows which suppliers are current.** - Checks everyone's status before buying → You buy knowingly rather than reviewing afterwards. **A retail chain audits with two weeks' notice.** - Reviews the file before it lands → The gaps close with time to spare. **A client asks for the origin of an exported consignment.** - Checks that shipment's file → You answer per shipment rather than per packhouse. **Field treatments are noted on paper.** - Captures the note at the moment → The record reaches the packhouse legible. **Certificates from a hundred growers pile up.** - Requests and chases automatically → The season starts with everyone current. --- --- id: KB-AL-006 url: https://app.codecontract.io/help/food-and-beverage/canned-and-processed-food idioma: en categoria: sector-alimentacion subcategoria: conservas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-007, KB-AL-004] citadoPor: [KB-AL-007, KB-AL-008, KB-AL-009, KB-AL-011, KB-AL-026] --- # Canned and processed food _Many ingredients, many suppliers, and a batch you must be able to trace backwards._ **Responde a:** ingredient traceability in canned food · processed food recall · food raw material supplier documentation · ifs brc audit paperwork A processed product has a problem fresh fruit does not: each batch is the sum of several ingredients, from several suppliers, with different dates. And when a recall comes, the question is not where the product came from, but which batches contain that particular ingredient. ## The two directions of traceability | Direction | The question | How long it can take | | --- | --- | --- | | Backwards | What is in this batch and from whom? | Minutes if linked; days if it lives in delivery notes | | Forwards | Which customers received this ingredient? | It decides the size of a recall | > [!IMPORTANT] > The second is what costs money. If you cannot narrow which finished batches a suspect ingredient went into, you must recall everything that might contain it — and the gap between narrowing and not narrowing is usually orders of magnitude. ## What to have before you need it 1. **A live file for each ingredient supplier** — Certifications, analyses, allergens and their document expiry dates. 2. **Each intake, linked to its documentation** — The delivery note and batch certificate arrive with the goods, not a month later. 3. **The production batch, with its ingredients inside** — That link is what lets you answer in both directions. 4. **And dispatches, with destinations** — Without this, forward traceability does not exist. > [!WARNING] > The most neglected point is the second: raw-material batch paperwork arrives by email to purchasing and stays there. In a crisis, that paperwork has to be where the batch is, not in a personal inbox. ## Customer audits Large chains audit own-brand suppliers with lists that repeat a lot: current certifications, allergen control, incident management, and a traceability exercise on a batch they pick on the spot. The last one is the only one you cannot prepare the night before. **En corto** - If the traceability drill takes minutes, the audit stops being frightening. - If it takes hours, you now know what to fix. - And running it twice a year costs less than failing it once. > [!NOTE] > All of this sits alongside what you already do for labelling and packaging: documents with expiry dates and an owner, the same mechanics as any supplier. **Is it needed for small production?** The obligation does not depend on size; the effort does. **What about ingredients bought from a distributor?** Ask the same: the distributor must be able to give you batch origin. **How long is it kept?** Longer than the product's shelf life, with margin. ## Ejemplos **A cannery receives an alert about a raw material batch.** - Checks which finished batches contain it and which customers received them → Recalls two specific batches instead of a month of production. **A batch carries fifteen ingredients from twelve suppliers.** - Ties each ingredient to the output batch → The backward journey is complete. **A supplier changes an ingredient's formulation.** - Reviews which references contain it → The change propagates to the affected labels. **A problem must be contained and nobody knows which batches carry it.** - Checks which production runs used that consignment → Scope narrows to what is actually affected. **Ingredient certificates are filed by supplier.** - Also files them against the consignment received → You answer per consignment rather than per supplier. **A client asks for a product sheet from a year ago.** - Keeps each version with its date → You provide the one that covered that sale. --- --- id: KB-AL-007 url: https://app.codecontract.io/help/food-and-beverage/bakery-and-pastry-allergens idioma: en categoria: sector-alimentacion subcategoria: panaderia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-006, KB-NO-007] citadoPor: [KB-AL-011, KB-AL-013, KB-CS-038, KB-AL-020] --- # Bakery and pastry: allergens _Many product lines, recipes that change, and information that has to be exact._ **Responde a:** allergen control in bakery · recipe change and labelling · allergen information for customers · flour supplier documentation A bakery has an unusual problem: hundreds of product lines, recipes adjusted by season or ingredient price, and consumer information that allows no approximation. Every recipe change is a label change and a spec change. ## Where it usually breaks | Point | What happens | Consequence | | --- | --- | --- | | Changing an ingredient supplier | The new one has a different allergen declaration | The spec stops being true with nobody noticing | | Recipe tweak in production | Changed on the floor and not on paper | Label and product no longer match | | New seasonal product | Launched fast, with a half-finished spec | It is the one that fails an inspection | | Information to catering customers | A PDF is sent and then ages | The customer misinforms using your data | > [!IMPORTANT] > The first row is the most treacherous. A supplier change is decided by purchasing on price or lead time, and nobody tells whoever maintains the specs. If supplier documentation enters through the same door as their onboarding, the change becomes visible. ## What must be linked 1. **A spec for each ingredient, with its supplier** — With allergen declaration and its date, not an email from three years ago. 2. **Each product line with its ingredients** — It is what lets you see, when one changes, which products are affected. 3. **Spec versions, retained** — So you can say what the product contained on the date it was sold. 4. **And what is delivered to customers, with proof** — Which version they received and when, especially for catering and institutional customers. > [!WARNING] > The fourth matters more than it looks. If a restaurant misinforms a customer using an outdated spec of yours, the conversation about who failed depends entirely on whether there is a record of which version you sent and when. ## Cross-contamination The other front is process, not paperwork: what is produced after what, how you clean between batches, and what is declared as "may contain". What is paperwork is the record of that cleaning and of the production order, which is what audits ask for. **En corto** - Every ingredient change triggers a review of the affected specs. - Every spec version is kept with its date. - And what is delivered to the customer is recorded, not merely sent. > [!NOTE] > It is the same mechanic as safety data sheets in chemicals: a document that changes, that must reach whoever uses it, and whose current version at any date you must be able to prove. **What about small bakeries?** Same obligation, fewer lines. Usually solved with a well-linked ingredient list. **How often should specs be reviewed?** Whenever something changes, plus a full annual review. **Must old specs be kept?** Yes: they prove what was declared at each moment. ## Ejemplos **A bakery switches flour supplier on price and nobody reviews the specs.** - Links each ingredient to its product lines - Reviews affected specs when the supplier changes → Finds twelve lines needed a different declaration before it reached the labels. **A recipe changes and the label takes weeks to follow.** - Reviews labels when approving the recipe change → Label and product say the same thing. **A supplier changes an ingredient without notice.** - Asks them to communicate any change of composition → The change arrives before the complaint. **There are two hundred references and nobody knows which carry an allergen.** - Checks which references use that raw material → The review narrows to the affected ones. **Allergen information lives on a separate sheet.** - Keeps it with the product's sheet → It is consulted where people look. **A client asks about the composition of a specific run.** - Checks the version current on that date → You answer per run rather than per catalogue. --- --- id: KB-AL-008 url: https://app.codecontract.io/help/food-and-beverage/olive-mills-and-oil-bottling idioma: en categoria: sector-alimentacion subcategoria: aceites audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-006, KB-CS-025] citadoPor: [KB-CS-036] --- # Olive mills and oil bottling _A short season, many growers, and a category you must be able to defend._ **Responde a:** olive mill traceability · grower delivery documentation · olive oil category analysis · milling season paperwork An olive mill compresses into three months what others spread over twelve: intakes from dozens or hundreds of growers, batches that get blended, analyses that define the commercial category, and a traceability demand that arrives much later, when the oil is already on the shelf. ## The four points where it is decided | Point | What to record | Why it matters later | | --- | --- | --- | | Olive intake | Grower, plot, quantity, date | It is the origin of all traceability | | Milling | Which intakes make up each batch | Without it, backwards tracing is impossible | | Analysis | Results that define the category | It is what supports what the label says | | Bottling and dispatch | Which batch went to which customer | It decides the scope of a recall | > [!IMPORTANT] > The second is recorded worst and makes everything else possible. If there is no record of which intakes make up each milling batch, backward traceability becomes an estimate, and an estimate does not answer an alert. ## What to require from growers **En corto** - Identification of the holding and its plots. - Treatment declarations, where your scheme requires them. - And whatever certifications your customer demands: organic, denomination, sustainability. Asking during the season, with the trailer at the gate, does not work. Ask beforehand, renew annually and check when the season opens — with reminders starting weeks earlier. ## What changes if you sell to large customers or export 1. **Audits with a traceability drill** — They pick a bottle off the shelf and ask you to reach the plot. 2. **Export documentation by destination** — Certificates and requirements that vary by country and change without notice. 3. **Product specs per customer** — With versions retained, because specifications change. 4. **And the ability to answer an alert fast** — Which is where you find out whether point two was properly recorded. > [!WARNING] > Beware paperwork arriving on paper mid-season: intake notes, analyses, cleaning records. If it is stacked to "process later", later arrives in March, with the season closed and half of it illegible. > [!NOTE] > The same scheme suits wineries, nut cooperatives and any processing with a short season and many contributors: the product changes, the problem does not. **Is the weighbridge log enough?** As a weight record yes; as traceability no, unless it links intake to batch. **What about deliveries from non-members?** The same documentation: traceability does not distinguish members. **How long must it be kept?** Longer than the bottled product's shelf life, with margin. ## Ejemplos **An olive mill gets a query about a batch bottled eight months earlier.** - Checks which intakes made up that batch and from which plots → Answers with actual origin detail instead of an estimate based on dates. **The season lasts six weeks and a hundred growers deliver.** - Reaches the season with everyone current → Intake does not stop over paperwork. **Each intake is noted by hand and written up later.** - Records at the moment of receipt → The data is exact rather than reconstructed. **A client asks you to evidence a specific grade.** - Checks the analyses attached to that batch → The grade is supported by what backs it. **Analyses arrive loose by email.** - Attaches them to the batch on receipt → The analysis lives with what it analyses. **Once the season ends, nobody knows what is missing.** - Checks the status per grower → Gaps close while the relationship is live. --- --- id: KB-AL-009 url: https://app.codecontract.io/help/food-and-beverage/aquaculture-and-fish-processing idioma: en categoria: sector-alimentacion subcategoria: pesca audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-006, KB-CS-024] citadoPor: [KB-AL-017] --- # Aquaculture and fish processing _Batches that merge at processing, and traceability you must be able to rebuild from the tray._ **Responde a:** traceability in a fish plant · aquaculture farming documentation · fresh fish batch traceability · processing plant health registration A fish processing plant faces traceability in its most awkward form: raw material comes in from several origins — own cages, the auction, imports — and product leaves in trays whose batch must be able to take you back to the water it came from. ## Where the chain breaks | Point | What merges | What to record | | --- | --- | --- | | Harvest or landing | Several cages or several landings the same day | Which origin enters each intake, with dates | | Processing | Different intakes in the same run | Which intakes make up each production batch | | Packing | Production batches across different formats | Which batch goes into which format and with what date | | Dispatch | Orders to several customers from one batch | Where each batch went | > [!IMPORTANT] > The second row decides everything else and is recorded worst, because plants work by shift rather than by batch. Without a record of which intakes made up each processing run, backward traceability stops being data and becomes an estimate based on dates — and an estimate does not answer a health alert. ## The detail that usually fails an audit > [!WARNING] > The health registration number on the label must be that of the **establishment that actually handled the product**, not of the company issuing the invoice. When processing or packing is subcontracted to another plant — common at seasonal peaks — that number changes and the label must follow. It is a failure invisible from the office and the first thing an inspector cross-checks. ## What to hold per supplier and per batch **En corto** - For raw material: origin, gear or production method, and its intake documentation. - For transport: temperature and time, because here the cold chain is part of the product. - For the plant: cleaning records, controls and the personnel on that shift. - And for the customer: which batch each dispatch note corresponds to. ## When an alert arrives 1. **Narrow forwards first** — Which customers received that batch. It decides the recall's size and is the most urgent. 2. **And backwards afterwards** — Which intakes made it up and what origin they came from. 3. **Record the decision, not only the action** — What was recalled, what was released and on what criteria, with a name and a time. > [!NOTE] > It applies equally to canning, salting, smoking and chilled ready meals: the process changes, but the point where traceability is lost is always the same — where several intakes become a single run. **What if we buy it already filleted?** Then your traceability starts at that purchase: ask your supplier for the origin batch and keep it. **How long must records be kept?** Longer than the product's shelf life, with margin; for frozen that means years. **Is a paper plant logbook enough?** It is if digitised the same day; at month end nobody can tell which run was which. ## Ejemplos **A plant receives an alert about a raw material consignment from three weeks earlier.** - Checks which processing runs included it and which customers got those batches → Recalls two specific batches instead of three weeks of production for lack of narrowing. **Batches merge at cutting and the trace breaks there.** - Records what went into each output batch → The backward journey survives cutting. **A client asks about one specific tray.** - Checks that tray's batch → You reach the intake. **Origin documentation arrives on paper with the box.** - Captures it on receipt → The paper stops being the only copy. **A batch must be flagged and nobody knows who received it.** - Checks what went out of that batch and where → Those affected are warned. **Supplier certificates expire without warning.** - Records validity on receipt → The warning arrives before the next purchase. --- --- id: KB-AL-010 url: https://app.codecontract.io/help/food-and-beverage/livestock-movements-and-treatments idioma: en categoria: sector-alimentacion subcategoria: ganaderia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-025, KB-AL-001] citadoPor: [KB-AL-015, KB-AL-023] --- # Livestock: movements and treatments _What you must be able to show for every animal that comes in, goes out or is treated._ **Responde a:** livestock holding register · animal movement documentation · veterinary treatment records · documentary control on a farm A livestock holding has been recording the same things for years: which animals come in, what goes out, what is treated and with what. The problem is rarely not having it: it lives in a notebook, in the vet's memory and in a drawer of prescriptions, and when someone asks it has to be reconstructed. ## The four things you are asked for | Front | What you must be able to show | Where it usually fails | | --- | --- | --- | | Identification | Which animals are present and since when | Arrivals and departures noted late | | Movements | Where each intake came from and where each departure went | The movement document stays on paper | | Treatments | What was administered, to which animal, when and who prescribed it | Noted at the time and never written up | | Feed | Which feed, from which supplier and which batch | Delivery notes filed with the invoices | > [!IMPORTANT] > The third row decides inspections and ages worst. What gets checked is not only that the treatment is recorded: it is that the recording date and the administration date agree, and that the treated animal can be followed through to its departure. A notebook written up in bulk at month end does not evidence that, even if the content is true. ## The hardest and most important point > [!WARNING] > A treatment's **withdrawal period** — the time that must pass before that animal or its output can go for consumption — only works if the treated animal is identified and its departure controlled. If treatment is recorded by pen or by batch without knowing exactly which animals received it, that control becomes an estimate. And that is the part that cannot be fixed afterwards. ## How to organise it without changing how you work 1. **Photograph the document at the moment** — Movement document, prescription, feed delivery note. From a phone, in the shed. 2. **The animal or batch as the thread** — Everything hangs off it: arrival, treatment, feed and departure. 3. **Warnings for what expires** — Health scheme tests, certifications, equipment and facility checks. 4. **And the vet supplying from their side** — Let them upload theirs by their link, with no account, instead of sending it by messaging. ## What changes if you sell to industry or a retail chain **En corto** - They will ask for consignment traceability and, increasingly, rearing or feeding conditions. - And audits with a drill: they pick an animal or a batch and ask for its full history. - That is answered in minutes when linked, and in days when it lives in a notebook. > [!NOTE] > Which registers are mandatory, the recording deadlines and what must be retained depend on the species, the region and the certification scheme. **Confirm what applies to you with your vet or your adviser**; this describes how to keep it findable, not what the rules require. **Can we keep using the notebook?** As a record yes; what does not hold up is reconstructing at month end what happened on the 3rd. **What about sheds with no signal?** Photograph and upload on the way out; what matters is not leaving it for the office. **Can the vet see the history?** With scoped access, yes, and it usually shortens consultations a lot. ## Ejemplos **A holding notes treatments in a notebook and writes them up at month end.** - Photographs the prescription at the time and links it to the treated animal → In an inspection, the recording date matches the administration date and departures can be controlled. **Movements are noted in a notebook in the shed.** - Records at the moment, from a phone → The data reaches the office legible. **A treatment is recorded and nobody revisits the withdrawal period.** - Lets the period warn by itself → The count does not depend on remembering. **An inspection asks about one specific animal.** - Checks its movement and treatment history → You answer from the record. **The vet's prescription stays on paper.** - Captures it and attaches it to the animal or batch → The paper stops being the only copy. **Temporary staff arrive and record differently.** - Uses the same record for everyone → The history is consistent. --- --- id: KB-AL-011 url: https://app.codecontract.io/help/food-and-beverage/ingredients-and-additives-what-comes-with-each idioma: en categoria: sector-alimentacion subcategoria: ingredientes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-006, KB-AL-007] citadoPor: [KB-AL-012, KB-AL-013, KB-AL-014, KB-AL-015] --- # Ingredients and additives: what comes with each _Four documents per ingredient, and the one that changes without warning forces you to redo labels._ **Responde a:** ingredient supplier documentation · additive technical datasheet · certificate of analysis per batch · supplier reformulation A processed product with fifteen ingredients drags sixty documents behind it, and they are not interchangeable: each answers a different question and expires differently. Conflating them is what makes a company believe its documentation is current when what it holds is three years old. ## The four per ingredient | Document | What it answers | How often it changes | | --- | --- | --- | | Technical datasheet | What it is, composition and intended use | When the supplier reformulates | | Allergen declaration | What it contains and what it may contain | With the datasheet, and sometimes silently | | Certificate of analysis | What that specific batch tested as | With every batch | | Supplier certifications | Their quality scheme or status | Annually, and it lapses without warning | > [!IMPORTANT] > The third row is the only one that runs **per batch** and the worst filed, because it arrives with the goods rather than with supplier onboarding. If the certificate of analysis is filed by supplier and not linked to the batch that came in, it exists but is useless: when a problem needs narrowing, you cannot say which analysis belongs to the material actually used. ## The change that forces you to review everything else > [!WARNING] > A supplier can reformulate an ingredient while still supplying "the same thing" commercially: same name, same code, new datasheet. And that new datasheet may carry a different allergen or a "may contain" that was not there before. **That change does not arrive as an alert, it arrives as a PDF attached to a routine email** — and if nobody compares it with the previous version, your labels stop being true without anyone deciding it. ## How to organise it so that shows up 1. **One datasheet per ingredient and supplier, versioned** — Keeping the previous one: that is what lets you see what changed. 2. **The certificate of analysis, linked to the intake batch** — Not to the supplier. It is the difference between narrowing and estimating. 3. **Which of your products use each ingredient** — So that when one changes, you know how many labels to review. 4. **And expiry warnings for supplier certifications** — They get checked exactly when a large order or an audit lands. ## What a customer audit asks for **En corto** - The current datasheet and the one in force when the batch under review was made. - The certificate of analysis for that raw material batch. - And what you did the last time a supplier changed something. The third distinguishes a system that works: holding the datasheets is not enough, you must be able to show that a change was detected and managed. > [!NOTE] > Requirements for ingredient, allergen and additive information depend on the product, the market and the certification scheme you hold, and they get updated. **Confirm exactly what must appear and with what scope with your adviser or certifier**; this describes what documentation exists and how to keep it linked. **Is the datasheet the salesperson sends enough?** As a reference yes; better the one quality or technical maintains, since that is the one updated. **What about ingredients bought from a distributor?** Ask for the manufacturer's datasheet: the distributor passes it on, it does not issue it. **How long must certificates of analysis be kept?** Longer than the shelf life of the product that batch went into. ## Ejemplos **A supplier reformulates an additive and sends the new datasheet in a routine email.** - Compares it with the previous version on receipt - Reviews the products using that ingredient → Spots a new "may contain" and corrects four labels before they reach the market. **An ingredient's composition changes and nobody reviews anything.** - Asks the supplier to communicate any change → The change arrives before the wrong label does. **Documents for an ingredient are missing and it is used anyway.** - Checks what is missing before accepting intake → The gap shows on receipt rather than at the audit. **An ingredient's four documents sit in four places.** - Gathers them in the reference's file → They are consulted at once. **A client asks for a specific ingredient's sheet.** - Checks that reference's file → You answer without phoning the supplier. **A document expires with the ingredient in stock.** - Records validity on receipt → The warning arrives before it is used. --- --- id: KB-AL-012 url: https://app.codecontract.io/help/food-and-beverage/wholesalers-the-link-that-only-moves-goods idioma: en categoria: sector-alimentacion subcategoria: mayoristas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-019, KB-AL-011] citadoPor: [KB-AL-030, KB-LG-026] --- # Wholesalers: the link that only moves goods _You make nothing and are still asked for documentation on everything, in both directions._ **Responde a:** food distributor documentation · wholesaler traceability what to keep · they ask me for specs of products i do not make · food distributor paperwork A wholesaler sits in the middle: buying from whoever makes it and selling to whoever serves or resells it. You transform nothing, and precisely for that reason you have a particular documentary problem — you are asked for papers on products you did not make, and asked from both sides. ## The two directions | Who asks | What they ask for | Where it comes from | | --- | --- | --- | | Your customer | Specs, allergens, product certificates | The manufacturer, through you | | Your customer | Your own registration and storage conditions | You | | An inspection | Where each batch came from and where it went | Your own intake and dispatch records | | Your supplier | Sometimes, who you sold their product to | You, during an alert | > [!IMPORTANT] > The second row gets forgotten: besides passing on the manufacturer's material, you have **your own** documentation that will be asked for — your registration, how you store and transport, and what you do if the cold chain breaks. A wholesaler who only forwards third-party papers holds half of what will be demanded. ## The costliest mistake > [!WARNING] > Forwarding a product spec **without checking it is current**. You received it two years ago, the manufacturer updated it, and your customer gets the old one with your email on top. If that spec no longer tells the truth — a different allergen, another composition — you are the one who sent it. It does not make you the manufacturer, but it does make you responsible for having distributed outdated information. ## How to organise it without going mad 1. **One spec per reference and supplier, versioned** — And knowing when it was last updated. 2. **An alert when the manufacturer sends a new one** — And a review of which customers received the previous version. 3. **Intakes and dispatches with batch numbers** — It is the only thing that answers "where did this batch go?" in an alert. 4. **And your own documentation current** — Registration, temperatures, cleaning, staff: what does not come from the manufacturer. ## When a manufacturer alert arrives **En corto** - First, forwards: which customers received that batch. - Second, whether you still hold stock to be quarantined. - And third, communicating it with evidence, not by phone. The order matters because time works against you: every hour, that product is closer to the end consumer. And whoever must warn your customers is you, not the manufacturer — they do not know who you sold to. > [!NOTE] > What each link must keep and for how long depends on the product and the country, and it gets updated. **Confirm it with your adviser or certifier**; this describes the mechanics of which documentation is passed on and which is yours. **Can I hand over the manufacturer's spec as it is?** Yes, if it is current. What does not work is forwarding the one on file without checking. **What if a customer asks for something the manufacturer will not give?** Request it formally and keep their answer: a refusal also places you. **How long should dispatch notes be kept?** Longer than the product's shelf life, with margin: they are the thread of forward traceability. ## Ejemplos **A distributor forwards a customer the spec it had on file from two years ago.** - Checks the version with the manufacturer before forwarding - Reviews which customers received the earlier one → Spots an added allergen and corrects it before it reaches a restaurant's menu. **A client asks for documentation on something you only moved.** - Passes the request to the maker and keeps the reply → You provide what the maker declares. **Documentation arrives from the supplier and is filed by supplier.** - Also attaches it to the consignment shipped → You answer per specific shipment. **A consignment must be flagged and nobody knows where it went.** - Records what went out and to whom → Those affected are warned. **Each client asks in a different format.** - Serves them from one current file → The underlying work happens once. **A supplier ceases to exist and their documentation is missing.** - Keeps its own copy of what was received → The supplier closing does not leave you with nothing. --- --- id: KB-AL-013 url: https://app.codecontract.io/help/food-and-beverage/ready-meals-every-recipe-carries-its-ingredients idioma: en categoria: sector-alimentacion subcategoria: preparados audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-011, KB-AL-007] citadoPor: [KB-CS-038, KB-AL-014, KB-GL-020, KB-AL-016] --- # Ready meals: every recipe carries its ingredients _You sell a dish, but what you will be asked for is the documentation of the fifteen things inside it._ **Responde a:** ready meal documentation · ingredient change and allergens · technical sheet for a prepared product · what a chilled meals client asks for A prepared product is, in documentation terms, the sum of all its ingredients plus what you do to them. The client buys one product code; what they review when approving you are the specifications, the allergens and the origin of every component, including those present in tiny amounts. ## What piles up behind one product code | Level | What documentation it carries | | --- | --- | | Each ingredient | Technical sheet, allergens, origin and its supplier's certificates | | The process | Your controls, treatments and conditions | | The packaging | Suitability for food contact | | The final product | Label, shelf life and what you declare to the client | > [!IMPORTANT] > What trips up most companies is not holding the documentation: it is **swapping an ingredient because of a stock shortage**. One day the usual supplier is out, you buy elsewhere, produce as normal and nobody writes anything down — but that batch carries a different ingredient, with different possible allergens and a different origin. Weeks later the label says one thing and the batch is another, and there is no way to tell which batches without reconstructing it by hand. ## What makes that manageable 1. **Each ingredient, a file with live documentation** — Updated when the supplier issues a new version, not when someone asks. 2. **Each recipe, the list of which ingredients it uses** — That is what lets you answer «what is in this» without opening fifteen folders. 3. **And every substitution noted with date and batch** — Five lines that day save a full reconstruction. 4. **With an allergen check before producing, not after** — It is the only moment the change can still be stopped. > [!WARNING] > What surprises people when selling to a chain: **they ask for your suppliers' documentation, not only your own**. And often dated recently, so a valid but expired supplier certificate blocks your product even when everything of yours is in order. That is why the expiry to watch is theirs, and it should warn earlier than seems necessary. ## When the client changes the rules **En corto** - A chain may require its own specification format: fill it from what you already hold. - It may ask for specific declarations your supplier does not give as standard: request them in writing. - And it may audit at short notice: what decides it there is how fast you can show it. > [!NOTE] > What must appear on the label, how allergens are declared and which controls are required depend on the food regulations that apply to you and on the destination market. **Your adviser or quality manager settles that**; the point here is that the information exists and is tied to the batch. **Should we keep every version of a spec sheet?** Yes: the one valid when that batch was made is the one they will ask for. **What about ingredients in tiny amounts?** They count the same for allergens, and they are the most forgotten. **Is the distributor's sheet enough?** If it is the manufacturer's, yes. If it is their own summary, it usually falls short. ## Ejemplos **A kitchen swaps an ingredient for two days over a stock shortage and notes nothing.** - Records the substitution with date and batch and checks allergens before producing → When the client asks about a specific batch, the answer comes from the file, not from memory. **A client asks for the documentation of all fifteen ingredients.** - Checks the product's file → It is provided at once rather than ingredient by ingredient. **An ingredient changes and the dish's sheet stays the same.** - Reviews the dishes containing it when the change arrives → The sheet describes what is made. **The same ingredient goes into twenty recipes.** - Checks which recipes use it → The review narrows to the affected ones. **A problem with an ingredient must be contained.** - Checks which production runs used it → Scope narrows to what is affected. **Allergens are worked out by hand each time.** - Derives them from the recorded ingredients → The calculation stops repeating. --- --- id: KB-AL-014 url: https://app.codecontract.io/help/food-and-beverage/packaging-that-touches-the-food idioma: en categoria: sector-alimentacion subcategoria: packaging audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-013, KB-AL-011] citadoPor: [KB-AL-028] --- # Packaging that touches the food _Packaging is not just another consumable: it carries its own paperwork, and it is approved for one use, not for any._ **Responde a:** food contact declaration of compliance · food grade packaging paperwork · food bags documentation · the auditor asks for packaging papers When people think of a food product's paperwork they think of ingredients. Packaging is bought the way labels or detergent are bought, and it enters the conversation the day an auditor asks which document backs that tray. ## What the packaging supplier must give you | Document | What it says | When to ask | | --- | --- | --- | | Declaration of compliance for the material | That it is suitable for food contact | When approving the supplier | | Which use it is declared for | Fatty, acidic, dry, hot, frozen… | Before deciding which product it holds | | Technical sheet for the material | Composition, weight, layers | Along with the declaration | | A current version for every change | If the material changes, the paper changes | Whenever the supplier changes anything | > [!IMPORTANT] > The second row is barely ever read and invalidates the most declarations: **suitability belongs not to the packaging but to the packaging for a specific use**. A bag declared for dry product at room temperature stops being backed if you put something fatty in it, or if it goes in the oven or the freezer. The document is still correct; what no longer fits is your use. And nobody spots that mismatch until someone compares the declaration with what is inside. ## What to check before switching packaging 1. **What it is declared for, not just whether it is «food grade»** — «Suitable» on its own says nothing: read what for. 2. **Whether your product fits that use** — Fat, acidity, temperature and contact time are what decide. 3. **That the change does not affect the label or shelf life** — A different material can change how the product holds up. 4. **And file the declaration with the date it came into use** — That is what ties each batch to the packaging used. > [!WARNING] > A silent change that catches many out: **the supplier can change the material without changing the reference**. Same code, same look, a different film supplier, and the declaration you have filed no longer matches what you are using. So it is worth asking for version confirmation at least yearly and whenever you notice any difference — a different shade, another stiffness, a seal that behaves differently. ## If you pack for others **En corto** - Your client will ask for the packaging documentation just as for the product's. - And if they choose the packaging, get their declaration: you still need it on file. - Secondary packaging, which does not touch the food, has lighter requirements but still gets justified. > [!NOTE] > Which requirements apply to each food-contact material, what the manufacturer must declare and which tests are required depend on food contact materials regulations and on the destination market. **Your adviser or quality manager confirms that**; here it is about the paper existing and matching the real use. **Is the distributor's declaration enough?** If it is the manufacturer's, yes. An email saying «it is food grade» is not. **Must every version be kept?** Yes: the one valid when that batch was produced is the one you will be asked for. **What about packaging that only groups items?** Lighter requirements, but be clear which touches the food and which does not. ## Ejemplos **A food workshop starts packing fatty product in bags declared for dry goods.** - Checks which use the packaging is declared for before switching product → The packaging stops being a finding waiting for someone to compare two documents. **Packaging is bought without its usage documentation.** - Requests it on the purchase order → The packaging arrives with what covers it. **Packaging is used for a product other than intended.** - Checks what use it is declared for → The decision is taken with the document in view. **The maker changes the material and nobody knows.** - Asks them to communicate any change → The change arrives before the question. **A client asks for the packaging documentation of one run.** - Checks that reference's file → You answer per run. **Packaging documentation expires without warning.** - Records validity on receipt → The warning arrives before the next purchase. --- --- id: KB-AL-015 url: https://app.codecontract.io/help/food-and-beverage/animal-feed-and-what-travels-with-it idioma: en categoria: sector-alimentacion subcategoria: animal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-010, KB-AL-011] citadoPor: [KB-AL-018, KB-AL-023] --- # Animal feed and what travels with it _What goes in the trough ends up in the food chain, which is why its paperwork looks more like food than raw material._ **Responde a:** animal feed documentation · what accompanies a feed raw material batch · feed traceability · asked for paperwork on the feed I use Making feed, distributing it or simply buying it for your animals places your company inside the food chain, even if the final product is two links away. That is why the documentation requested looks so much like food documentation: in practice, that is what it is. ## What travels with each batch | Element | What it proves | Who issues it | | --- | --- | --- | | Product identification and its batch | Exactly what it is and from which production run | The manufacturer | | Composition and raw materials | What it contains | The manufacturer, on the label or spec | | Origin of the raw materials | Where each component comes from | Requested backwards, supplier by supplier | | The period's analyses | That what must be controlled is controlled | The lab, in-house or external | | Transport document | Who moved it and under what conditions | The haulier | > [!IMPORTANT] > The overlooked point that decides an investigation is transport: **a tanker or lorry that previously carried something else can contaminate the whole batch**. So what you keep is not only what arrived, but what it arrived in and what that vehicle carried before. It is information the haulier holds and nobody asks for until it is needed — and by then it cannot be reconstructed, because the lorry has made fifteen more trips. ## What to hold per batch 1. **Docket with batch and quantity, tied to the silo or store it entered** — Without that, the batch dissolves the moment it is unloaded. 2. **The product spec in force that day** — If the maker changes the formula, the spec changes. 3. **Evidence of transport cleaning, where applicable** — It is what gets asked for in an alert and is rarely kept. 4. **And which animals or production batch it went to** — It is the link to whatever leaves the farm. > [!WARNING] > What surprises those who only buy feed: **if there is an alert one day, the question does not go to the manufacturer, it comes to you**. Whoever must say which batch came in, when and which animals it went to is whoever used it, not whoever produced it. And that answer counts in hours or not at all — by then the product has moved on. Which is why noting the batch at unloading, a seemingly minor formality, is the piece holding everything else up. ## If you also manufacture or blend **En corto** - Every blend carries the documentation of everything inside it. - A supplier swap over a stock shortage changes that batch's composition. - And what you produce for third parties carries your label: you answer for what it says. > [!NOTE] > Which records are compulsory, what must appear on the label and which controls apply to each product type is set by animal feed regulations and your region. **Your adviser or vet confirms that**; here it is about being able to follow the batch backwards and forwards. **Is the delivery note enough as traceability?** It is the basis, if it carries a batch. Without one it is a delivery slip. **What if I mix two batches in the same silo?** Record it: from then on what is inside is both. **How long to keep these records?** Longer than the animal or the product that came out of there. ## Ejemplos **A farm receives an alert about a raw material and never noted the batch at unloading.** - Records batch and silo on every unload, and which animals it went to → The next query is answered within the hour, which is the window where an answer counts. **Raw materials arrive without their documentation.** - Checks what is missing before accepting intake → The gap shows on receipt. **A client asks for the traceability of a delivered consignment.** - Checks that outbound movement's file → You answer per consignment. **Raw materials from several origins are mixed.** - Records what went into each batch produced → The backward journey is complete. **A supplier certificate expires with material in the silo.** - Records validity on receipt → The warning arrives before producing with it. **A batch must be flagged and nobody knows which farms received it.** - Checks what went out and where → Those affected are warned. --- --- id: KB-AL-016 url: https://app.codecontract.io/help/food-and-beverage/withdrawing-a-product-from-the-market idioma: en categoria: sector-alimentacion subcategoria: distribucion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-013, KB-GL-020] citadoPor: [KB-CS-007] --- # Withdrawing a product from the market _A recall is not improvised at nine on a Friday night. It is rehearsed beforehand — and what you rehearse is finding the paperwork._ **Responde a:** how to run a product withdrawal · food recall mock exercise · i have to withdraw a batch what now · product recall steps A customer calls and says something is not right. Or your supplier warns that an ingredient they shipped you has a problem. From that minute on, everything you decide hangs on one thing: **how fast you can say where each batch went**. And that is not decided that night; it was decided the day you set up your records. **Withdrawal and recall** — Withdrawing is taking the product out of the chain before it reaches the consumer. Recalling is going after it once it has. The worse your answer to «where is it?», the closer you are to the second. ## The clock, hour by hour | Moment | What you must be able to say | Where it comes from | | --- | --- | --- | | First hour | Which batch it is and what is in it | The production record | | First hours | How much was made and how much is still here | The warehouse | | Same day | Who it was shipped to and in what quantity | The delivery notes | | Right away | What else was made with the same ingredient or line | The link between batches | | Afterwards | What was done and why, with timestamps | The file you are creating right now | > [!IMPORTANT] > The row that sinks most companies is the fourth: **scope**. With poor records, the only honest answer is «we withdraw everything from that month», and that multiplies the cost twentyfold. With records linking the ingredient batch to product batches and those to customers, the withdrawal is contained to what is genuinely affected. It is literally the difference between a bad afternoon and a bad quarter — and it is decided months earlier, in how batches get recorded. ## The mock exercise, the only thing that proves it works 1. **Pick a random batch from a few months back** — Random and old. Yesterday's is remembered by everyone and proves nothing. 2. **Reconstruct backwards: what it was made from** — Ingredients, suppliers and their batches. 3. **And forwards: where it went** — Customers, quantities and dispatch dates. 4. **Time it and note where you got stuck** — The sticking point is the finding; the total time is only the headline. > [!WARNING] > What most often breaks a mock exercise is not traceability: **it is that the information lives in different places and different formats**. Production in a spreadsheet, delivery notes in the ERP, the supplier's email in the inbox of someone who is off today. Every hop between systems is half an hour, and in a real withdrawal those half hours are product still moving towards the consumer. So the goal is not «having the data», it is having it **in one place and within reach of more than one person**. ## What to write down while it is happening **En corto** - Who decided to withdraw, at what time, and with what information on the table. - Who was notified, when and through which channel — including those who never replied. - What came back, what was destroyed and under which document. - And what was changed afterwards so it does not recur, which is the first thing they ask. > [!NOTE] > When you are required to inform the authorities, within what deadline and by what route, and how withdrawal differs from recall in your specific case, is determined by the applicable food rules. **Your quality manager or adviser settles that, and it is worth having written down BEFOREHAND**; here we explain how to reach that call with the answers already prepared. **How often should we run a mock exercise?** At least yearly, and whenever a system or a major supplier changes. **What if the problem comes from my supplier?** The alert is theirs, but withdrawing YOUR product is yours. Start with scope. **Do we notify even if nothing reached anyone?** That depends on the case and is not decided in the heat of it: have it checked in advance. ## Ejemplos **A supplier flags a problem with an ingredient and you do not know which products used it.** - Links the ingredient batch to product batches in the production record → Scope is contained to the affected batches instead of withdrawing a month's output. **The annual mock exercise stalls because delivery notes are in the ERP and production is in a spreadsheet.** - Brings both records into the same batch file - Times it and notes where it stalled → The next exercise drops from hours to minutes as the hops between systems disappear. **Once the withdrawal is over, you are asked to explain what was done and who was told.** - Records decisions, notifications and replies with timestamps as it happens → The file is handed over complete, with nothing reconstructed from memory. **You must decide who to warn and there is no record of what went out.** - Records which batch went to which customer → Those affected are warned rather than the whole base. **The recall is only rehearsed when it actually happens.** - Tries once to locate a random batch → The real response time is known beforehand. **The documents needed sit in four places.** - Gathers them in the batch's file → The decision is taken with everything in view. --- --- id: KB-AL-017 url: https://app.codecontract.io/help/food-and-beverage/fishmongers-where-each-piece-comes-from idioma: en categoria: sector-alimentacion subcategoria: pescados audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-009, KB-GL-020] citadoPor: [KB-AL-019, KB-AL-029] --- # Fishmongers: where each piece comes from _The counter mixes what the box kept apart. What you must be able to say about each piece is decided on receipt, not at the sale._ **Responde a:** traceability in a fishmongers · fresh fish labelling requirements · where the fish i sell comes from · documentation accompanying fish Fish arrives in boxes, each with its label and its data. On the counter it is laid out by species and size, which is how customers ask for it. Between those two things there is a jump: the box knew where each piece came from and the counter no longer does, unless someone wrote it down along the way. ## What you must be able to say about each piece | Detail | Where it comes from | | --- | --- | | Which species, with its scientific name | The box label | | Where it was caught or farmed | The same, and not always the supplier's location | | Whether it is wild-caught or farmed | The same | | Whether it has been frozen | The delivery note and your own handling | > [!IMPORTANT] > **Traceability is not lost at the counter: it is lost when the boxes are emptied.** While the box is intact, everything is on its label. The moment the goods move to a tray, the information exists only if someone copied it somewhere. So the recording happens on receipt, with the box in front of you, not at the end of the day trying to reconstruct what was in each tray. ## Two things that complicate the counter **En corto** - Mixing two different deliveries of the same species in one tray: from then on they cannot be separated. - Defrosted fish sold as fresh: the most closely watched point, and you must be able to show what was what. - Pieces that are cut or prepared: they still carry the whole piece's origin. - And stock set aside for an order: without its label behind it, it becomes anonymous. > [!WARNING] > A confusion that costs money with suppliers: **the commercial name and the species are not the same thing, and several different species are sold under one popular name**. If the box arrives with the commercial name and nothing else, the detail you will be asked for is missing. It is not bureaucratic detail: it is what lets you respond when an alert affects one specific species and not the one you thought you were selling. > [!NOTE] > What information must accompany each fishery product, how it must be presented to the consumer and which records must be kept is set by the applicable rules, and varies for fresh, frozen, processed or retail sale. **Your adviser or health authority settles that**; here we explain where it breaks in practice. **Do I have to keep the box labels?** Keep at least their information. It is the source of everything else. **What if I mix two deliveries of the same species?** Then the piece belongs to both, and an alert affects all of it. **Can defrosted fish be sold?** Yes, but identified as such. It is among the most closely watched points. ## Ejemplos **Boxes are emptied in the morning and by mid-afternoon nobody knows which delivery is in which tray.** - Records the label information on receipt, with the box in front of them → Every tray can say where it came from with nothing reconstructed. **An alert arrives affecting one species and the delivery note carries only the commercial name.** - Requires the scientific name from the supplier on every delivery → Whether you are affected is known in minutes rather than after asking and waiting. **Two different deliveries of the same fish get mixed in one tray.** - Keeps deliveries apart while possible and records it when they merge → An incident is contained to one delivery instead of the whole counter. **A box arrives and its origin is not recorded.** - Records the origin on receipt → The fact exists when somebody asks. **The counter mixes pieces from two intakes.** - Records which intake supplied each display → You can say where each piece came from. **A customer asks about what they bought yesterday.** - Checks what was recorded that day → You answer from the record. --- --- id: KB-AL-018 url: https://app.codecontract.io/help/food-and-beverage/bulk-grain-when-the-silo-mixes idioma: en categoria: sector-alimentacion subcategoria: cereales audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-015, KB-GL-020, KB-AL-024] citadoPor: [KB-AL-025] --- # Bulk grain: when the silo mixes _In bulk, the batch is not defined by the product but by the silo. And every lorry that arrives redefines what is inside._ **Responde a:** bulk grain traceability · how a batch is defined in a silo · incoming grain analysis · mixing harvests in the same silo With packaged product, every unit carries its batch on it. In bulk nothing carries anything: there is a silo holding twenty tonnes that arrived on six lorries from four different fields, and the seventh will unload on top of it this afternoon. **Bulk batch** — Whatever you decide a batch is, normally by silo and filling period. It is not given by the product: define nothing and the batch becomes «the whole silo since it was last emptied», which is usually far too much. ## The four decisions that determine everything | Decision | Consequence | | --- | --- | | When a batch is closed | Defines how much is held if something fails | | Whether deliveries are mixed | Every mix ties the fate of both together | | What is analysed and when | Decides whether a problem shows on entry or on exit | | What is kept per lorry | The only thing that lets you look backwards | > [!IMPORTANT] > **The rule governing bulk: every discharge onto existing product extends the batch both backwards and forwards.** If this afternoon's lorry brings a problem, it affects everything in the silo — and what left this morning came out of that same silo. Which is why the incoming analysis, before discharge, is not a formality: it is the only moment when a problem still fits inside one lorry. ## What must be reconstructable 1. **Which lorry discharged into which silo, and when** — With times. It underpins everything else. 2. **Who it came from and from what origin** — Supplier and, where applicable, field or area. 3. **What analysis was run on it and with what result** — The lorry's, not only the silo's at the end. 4. **And which despatch went to whom, from which silo** — Without this nothing can be bounded going forward. > [!WARNING] > The point that most often breaks traceability in practice: **transfers between silos**. Product is moved to make room, to blend qualities, or because a silo needs maintenance, and that operation is almost never recorded as carefully as an intake. From then on the two silos share a history and nobody knows it. A transfer log, even a notebook, is worth more than any other paper on the day something has to be bounded. > [!NOTE] > Which controls, analyses and records grain destined for food or feed requires, and what limits apply to each contaminant, is set by food and feed rules. **Your adviser or quality manager settles that**; here we explain the organisational part that decides whether those controls are worth anything. **Can I have one batch per silo?** That is the usual approach. What matters is deciding when it closes. **Does every lorry need analysing?** It depends on the product and its destination. Testing on entry is what bounds it. **What if I mix two years' harvests?** You can, but the resulting batch belongs to both. Write it down. ## Ejemplos **A lorry with a problem discharges onto twenty tonnes and the whole silo has to be held.** - Tests on entry, before discharging onto existing product → The problem stays inside one lorry instead of multiplying twentyfold. **Product is transferred between two silos to make room and nothing is recorded.** - Keeps a transfer log with date, source and destination → The two silos stop sharing a history nobody can reconstruct. **The batch is «the whole silo since it was emptied», and that is six weeks.** - Defines when a batch closes, and actually closes it → An incident is bounded to days of filling rather than a month and a half. **Every lorry that arrives changes what is in the silo.** - Records each intake with its origin and date → The silo's contents are explicable. **A client asks about one specific outbound movement.** - Checks which intakes made up the silo at the time → You answer with what was there that day. **Unloading happens into the wrong silo.** - Records the location on unloading → The error is caught before mixing. --- --- id: KB-AL-019 url: https://app.codecontract.io/help/food-and-beverage/frozen-food-the-date-nobody-records idioma: en categoria: sector-alimentacion subcategoria: congelados audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-017, KB-CS-031] citadoPor: [KB-AL-021] --- # Frozen food: the date nobody records _The freezer preserves the product, not its history. What was not recorded on the way in is not in there._ **Responde a:** date of freezing requirement · how long can i keep a product frozen · freezer temperature records · defrosted product what do i do A well-run freezer has one deceptive virtue: **the product looks exactly the same six months later**. That makes the chamber the place where undecided things end up, and means the question «when is this from?» has no answer by the time somebody finally asks it. ## The three details you must be able to give | Detail | When it is recorded | | --- | --- | | What it is and which delivery it came from | On the way in, never later | | **When it was frozen** | **On the way in. The one always missing** | | Until when it can be used | On the way in, derived from the above | > [!IMPORTANT] > **With no freezing date nothing can be calculated, and that detail cannot be reconstructed afterwards.** Not by looking at the product, not from its appearance, not by asking: either it was recorded that day or it is gone. A hand-written label on the way in solves in full a problem that otherwise forces a choice between throwing away good product or using product you know nothing about. ## What is worth having in place 1. **A label on everything that goes in, without exception** — What it is, which delivery, which day. Thirty seconds a tray. 2. **A temperature record for the chamber** — And keep it: it earns its place the day someone asks about a specific period. 3. **A periodic review of what is inside** — Freezers accumulate, and what accumulates unwatched expires in there. 4. **And what happens to defrosted product** — Written beforehand, not decided with the door open. > [!WARNING] > The two delicate moments are not storage, which is the easy part: **they are the way in and the way out**. On the way in, product arriving at a doubtful temperature and put in «to save it» — that saves nothing, it freezes the problem. On the way out, defrosted product refrozen because it ended up unused: the decision most often taken in a hurry and least defensible afterwards. Both are solved by deciding beforehand, not in the moment. > [!NOTE] > Which temperatures and records each type of frozen product requires, what must be indicated to the consumer, and what may or may not be refrozen is set by food rules. **Your quality manager or adviser settles that**; here we cover the organisational failure no regulation fixes: not writing down the date. **Is the freezing date mandatory?** It depends on the product and destination. Even where it is not, without it you can calculate nothing. **Can I refreeze something defrosted?** It is the least defensible decision afterwards. Have it written down in advance. **How long do I keep temperature records?** Long enough to cover the life of the product despatched in that period. ## Ejemplos **An unlabelled tray turns up at the back of the chamber and nobody knows when it is from.** - Labels everything going in with what, which delivery and which day → The choice between binning good product and using unknown product disappears. **Goods arrive at a doubtful temperature and go into the freezer «to save them».** - Decides beforehand what happens in that case and writes it down → The problem does not get frozen along with the product to reappear months later. **You are asked about temperatures for a specific period and the records were not kept.** - Keeps the chamber's record for as long as the product despatched then lasts → The question is answered with data instead of recollections. **Something is frozen and the intake date is not recorded.** - Records the date when it goes in → Time inside is a fact rather than an impression. **There are old pallets and nobody knows their date.** - Shows what has been stored longest → Rotation is decided on data. **A client asks about the freezing date.** - Checks what was recorded at intake → You answer with a date. --- --- id: KB-AL-020 url: https://app.codecontract.io/help/food-and-beverage/restaurants-the-papers-nobody-has-to-hand idioma: en categoria: sector-alimentacion subcategoria: restauracion audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-007, KB-CS-033] citadoPor: [KB-CS-019] --- # Restaurants: the papers nobody has to hand _In a kitchen the paper is not missing: finding it is. And whoever asks tends to turn up at the worst moment of service._ **Responde a:** paperwork a restaurant inspection asks for · supplier documents in hospitality · allergens and staff training in a restaurant · what an inspector asks a restaurant for **A kitchen's problem is not lacking the paperwork: it is that it is split between a folder in the office, the owner's inbox and the head chef's memory.** And whoever asks for it does not give notice, or wait for service to end. ## What gets asked for, and where it really is | What they ask for | Where it usually sits | | --- | --- | | Suppliers and their certificates | In the inbox of whoever places orders | | Allergen information | On an old menu that no longer matches the dishes | | Staff training | In the accountant's folder | | Temperature records | In a notebook, if someone filled it in this week | > [!IMPORTANT] > **The allergen row causes the most trouble, for a reason that is not documentary: the menu changes and the information does not.** A supplier is switched, an ingredient replaced with a similar one, a new weekend dish appears — and the sheet still describes the dish of eight months ago. That is not a filing failure: it is wrong information in front of someone who may have a serious problem. ## The minimum, which is little and changes a lot 1. **One folder, and more than one person able to open it** — The owner is not always in, and an inspection does not come back another day. 2. **Supplier certificates with their expiry dates** — Almost all of them lapse, and it is always discovered late. 3. **The allergen sheet tied to menu changes** — If the dish changes, the sheet changes. Same day. 4. **And staff training, including the summer starter's** — That is the one always missing, because they started in a rush. > [!WARNING] > A case that recurs in small kitchens and is worth settling in advance: **the trusted long-standing supplier you hold not a single paper from**. Nobody doubts them, and yet if you are asked where those goods came from, you cannot answer. Asking is not distrust — it is exactly what will be asked of you, and they understand perfectly because they get asked too. > [!NOTE] > What documentation a food service establishment must hold, which records must be kept and how often is set by health regulations and their regional or local application. **Your adviser or health authority settles that**; here we cover the real problem, which is rarely having the paper and usually finding it. **Does everything have to be on the premises?** Whatever can be asked for on the spot, yes, or accessible on the spot. **What about seasonal staff?** Same as permanent. That is where training is most often missing. **Is keeping it on a phone acceptable?** If more than one person can find it and it does not depend on a single handset. ## Ejemplos **An inspection arrives during service and only the owner can open the folder, and they are out.** - Keeps the paperwork in one place two people know how to open → The visit is resolved on the spot instead of with a deadline and a second round. **A supplier changes and the allergen sheet still describes the previous recipe.** - Ties the sheet review to menu or supplier changes, same day → What the customer is told matches what is on the plate. **Not a single paper exists for the long-standing supplier.** - Asks them for documentation, explaining it is the same being asked of them → The file can say where the goods came from without awkwardness. **An inspection arrives in the middle of service.** - Keeps the file accessible from a phone → It is shown without stopping the kitchen. **The papers sit in a folder in the office.** - Captures and stores them in the file → They are found from anywhere. **A small supplier never sends their sheet.** - Asks for little, with an easy place to upload → The sheet arrives without chasing. --- --- id: KB-AL-021 url: https://app.codecontract.io/help/food-and-beverage/the-cold-chain-between-two-companies idioma: en categoria: sector-alimentacion subcategoria: cadenafrio audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-019, KB-LG-017] citadoPor: [KB-LG-020] --- # The cold chain between two companies _Temperature is well controlled inside each company. Where it breaks is on the loading bay, which belongs to nobody._ **Responde a:** who is liable for temperature in transit · cold chain break who pays · temperature record at delivery · the lorry arrived above temperature Inside your chamber there are records. Inside the lorry there are records. And between the two there are fifteen minutes on a loading bay where the product belongs to nobody — which is exactly where the cold chain breaks and where, afterwards, nobody can prove anything. ## The three moments, and who answers in each | Moment | Whose it is | What usually fails | | --- | --- | --- | | Before loading | The consignor's | Product already off temperature gets loaded | | **In transit** | **The carrier's** | **The record exists but nobody asks for it** | | At unloading | Decided right there | The note is signed without measuring anything | | Afterwards | The consignee's | Where the problem came from can no longer be known | > [!IMPORTANT] > **Signing the delivery note without checking the temperature is accepting the goods as they arrived.** It is the most routine gesture on the bay and the one that decides who carries the problem: after that signature, showing the product arrived out of range is nearly impossible. Measuring on receipt and noting it on the note takes a minute and completely changes next week's conversation. ## What to ask for and keep 1. **The transport temperature record** — It nearly always exists. Ask for it, because unasked nobody hands it over. 2. **Your own measurement on receipt, recorded** — On the note, with the time, and signed by both where possible. 3. **What to do if it arrives out of range, decided beforehand** — Accept, reject, or accept under reservation. Not improvised on the bay. 4. **And your measuring equipment verified** — An uncalibrated thermometer turns your evidence into theirs. > [!WARNING] > The dispute that most often ends badly is the minor incident: **product arrives two degrees high, is accepted «because it looks fine» and nothing is recorded**. If a claim follows weeks later, the incident does not exist — and without it, the history says every delivery from that supplier was fine. Recording a minor incident is not picking a fight: it is the only thing that lets a pattern be seen when it repeats. > [!NOTE] > Which temperatures each product requires, how transport must be documented and how liability is split between consignor, carrier and consignee depends on the product and what was agreed. **Your adviser or quality manager settles that, and it belongs in the transport contract**; here we explain where the evidence is lost in practice. **Can I reject a delivery over temperature?** It depends what was agreed. Decide it before the lorry arrives. **Is the lorry's display good enough?** It is a data point, not evidence. Measure yourself and record it. **What if I accept and a problem follows?** Which is why accepting under recorded reservation beats simply signing. ## Ejemplos **A lorry arrives two degrees high, is accepted because the goods look fine, and nothing is recorded.** - Measures on receipt and records the incident on the note, even while accepting → When it recurs there is a history to show instead of an impression. **A claim arises and the transport temperature record was never requested.** - Asks for the record on every delivery and files it with the note → Which leg it happened on can be stated, instead of blame being shared blindly. **Out-of-range product arrives and the decision is taken on the bay with the lorry waiting.** - Writes down beforehand what is accepted, rejected, or accepted under reservation → The decision stops depending on who happens to be on the bay that day. **Temperature is logged inside but not at handover.** - Records the condition on despatch and on receipt → The loading bay stops being no man's land. **There is a dispute about where the chain broke.** - Compares the two handover records → The dispute closes on data. **The carrier logs in their system and it never reaches you.** - Collects and stores what they provide → Your own record does not depend on someone else's. --- --- id: KB-AL-022 url: https://app.codecontract.io/help/food-and-beverage/the-field-record-and-what-gets-asked-later idioma: en categoria: sector-alimentacion subcategoria: agricultura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-025, KB-AL-005, KB-AL-025] citadoPor: [KB-AL-029] --- # The field record and what gets asked later _It is kept out of obligation and ends up serving another purpose: it is the only thing that answers when a client asks about a consignment._ **Responde a:** field record what to write down · asked for treatments on a consignment · traceability from the field · paperwork clients ask farmers for The record is kept because it must be, and is often filled in the day before somebody asks for it. And yet, when a client asks why a particular consignment is as it is, or when an alert comes, it is the only document that can answer — because it is the only one linking a field to a date and to what was done that day. ## What you will later be asked about a consignment | Question | Comes from the record if it holds… | | --- | --- | | Which field did it come from? | Harvest recorded by field and date | | What treatments did it have? | Product, rate and date recorded | | Were the intervals respected? | Treatment date and harvest date recorded | | What water was it irrigated with? | Source recorded, where it applies to your crop | > [!IMPORTANT] > **The left-hand column are a client's questions, not an inspector's — and they arrive far more often than any inspection.** That is the practical reason to keep it current: it is not administrative paperwork, it is what lets you keep a client who is asking whether they can trust that consignment. A record filled in afterwards cannot do that, because the dates match nothing. ## What makes it genuinely useful **En corto** - Recording the same day, even roughly on a phone: the date is the point. - Making the field the unit, not the whole holding: otherwise everything is one batch. - Keeping the invoices for what is applied, which is what supports the entries. - And recording what was not done when planned: it explains the gaps. > [!WARNING] > The gap almost nobody bridges, where everything is lost: **between harvest and what goes out on the lorry**. In the field there are plots; in the store there are pallets. If loading does not record which plots go in each consignment, the whole record never connects to the client: you can say what you did in each field and cannot say which field reached them. One line on the delivery note bridges it entirely. > [!NOTE] > Which entries are mandatory, in what detail and for how long they must be kept depends on the crop, the destination and the applicable rules, plus whatever each private certification requires. **Your agronomist or adviser settles that**; here we explain why keeping it current pays off even if nobody asked. **Is recording it on a phone acceptable?** Yes, if done the same day and then preserved. **Do I have to record by field?** Without it you can bound nothing later. It is the useful unit. **Can my clients ask for it?** They will ask, and more often than the authorities do. ## Ejemplos **The record is filled in the day before an audit and the dates match nothing.** - Records on the day, even on a phone, with the right date → The record can answer client questions, not merely pass a review. **A client asks about a consignment and nobody knows which fields it came from.** - Records on the delivery note which plots go in each consignment → What was recorded in the field connects to what the client received. **Everything is recorded at holding level and one incident means reviewing the whole season.** - Changes the recording unit to the field → An incident is bounded to a few hectares instead of the entire harvest. **The field record is filled from memory at the end.** - Records at the moment, from a phone → The data is exact. **A client asks about one specific consignment.** - Checks what was recorded on those dates → You answer from the record rather than from memory. **The record is on paper and gets wet or lost.** - Captures and stores it at once → The record outlives the field. --- --- id: KB-AL-023 url: https://app.codecontract.io/help/food-and-beverage/vet-prescriptions-and-withdrawal-periods idioma: en categoria: sector-alimentacion subcategoria: ganaderia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-010, KB-AL-015] citadoPor: [KB-AL-031] --- # Vet prescriptions and withdrawal periods _The treatment is nearly always recorded properly. What fails is the countdown that starts that day and that nobody revisits._ **Responde a:** farm veterinary treatment records · withdrawal period before selling · how long to keep vet prescriptions · medicine documentation on a livestock farm An animal is treated, the vet leaves the prescription and someone records it. So far, nearly everyone does it properly. The failure comes later: **that treatment opens a countdown, and the countdown lives in the head of whoever was there that day** — who may be the same person off duty the weekend the lorry comes. **Withdrawal period** — The time that must pass between the last treatment and the moment that animal or its produce may go for consumption. It starts on the day of treatment and does not depend on how the animal looks. ## Where it breaks, by frequency | What happens | How to avoid it | | --- | --- | | It is treated and recorded, but no end date is set | Record the day it becomes available again, not only the treatment day | | The treated animal is not identifiable in the field | A visible mark, not only a note in the book | | The batch leaves on a day the person who knew is away | Have the fact live in the record, not in a person | | The treatment changes midway and nobody recalculates | Every change restarts the count | > [!IMPORTANT] > **Record the date the period ends, not only the treatment date.** It is a tiny change and it prevents the whole error: it forces the calculation to be done once, on the day the information is in front of you, instead of leaving it for loading day, in a hurry and possibly with someone else. The difference between the two ways of writing it down is exactly the difference between a record that protects and one that merely documents. ## What must be producible afterwards **En corto** - What was administered, to which animal or batch, on what date and on whose instruction. - The prescription that backs it. - The invoices or delivery notes for the medicines, which is what reconciles with the entries. - And what was done with the produce during the period, if any. > [!WARNING] > The case that most often ends in a serious problem is not the forgotten treatment: **it is the treated animal that rejoins the rest because the mark fell off or was never applied**. The record holds everything perfectly and in the pen it can no longer be told which one it was. Physical identification at the moment of treatment is not a duplicate of the paper — it is the only thing connecting the paper to the animal. > [!NOTE] > Which records animal health and veterinary medicine rules require, how long they must be kept and what period each product carries is determined by the prescription and the rules in force. **Your vet settles that**; here we explain the organisational failure that turns a correct record into a real problem. **How long do I keep prescriptions?** Whatever the rules say, usually longer than feels reasonable. Ask once and fix it. **What if the animal is sold before the period ends?** That is precisely the problem the record exists to prevent. **Is noting it in the book enough?** On paper yes; in the field the animal must also be distinguishable. ## Ejemplos **The treatment is recorded but not when the period ends, and the lorry comes on a Saturday.** - Records the period's end date on the day of treatment → The calculation is done before it is needed and does not depend on who is around. **A treated animal loses its mark and rejoins the rest of the batch.** - Physically identifies the animal at the time of treatment and verifies it → The paper stays connected to the animal, which is the only thing making the record useful. **The treatment changes midway and nobody redoes the count.** - Treats every change as a new date and recalculates the period → The period describes the last treatment rather than the first. **The treatment is recorded and the withdrawal period is worked out mentally.** - Lets the period warn by itself → The count does not depend on remembering. **Several animals are treated and the period is applied to one.** - Records which animals were included in the treatment → The period reaches everyone it should. **The prescription stays in the vet's pocket.** - Captures it and attaches it to the treatment → The paper stops being the only copy. --- --- id: KB-AL-024 url: https://app.codecontract.io/help/food-and-beverage/cutting-one-carcass-into-twenty-products idioma: en categoria: sector-alimentacion subcategoria: carnica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-001, KB-GL-020] citadoPor: [KB-AL-018] --- # Cutting: one carcass into twenty products _It comes in identified and leaves in twenty boxes. What decides whether you can look back is how it is grouped, not how it is cut._ **Responde a:** cutting room traceability · how cutting batches are grouped · which carcass did this cut come from · production batch in meat processing At intake, each carcass carries its identification and everything is clear. At despatch there are boxes by product, not by origin. Between the two is a room where several carcasses are worked at once, and what happens there decides whether it will ever be possible to say where a given cut came from. ## The three ways to group, and what each costs | How the batch is grouped | Precision | Working cost | | --- | --- | --- | | By individual carcass | Highest | High: only worth it for very specific product | | **By day or by shift** | **Reasonable** | **What almost everyone does** | | By week | Low: an incident takes a lot with it | Low, and expensive on the day it fails | > [!IMPORTANT] > **The decision is economic rather than technical, and it should be taken looking at the worst day: the bigger the batch, the more product is held when something fails.** Grouping by week saves a few minutes of recording a day and can cost a whole week's production. Grouping by shift costs a little more and bounds the problem to hours. It is literally the same calculation as defining a batch in any sector, only here it bites sooner. ## What must be recorded without exception 1. **Which carcasses entered each cutting batch** — It is the link between what arrived and what leaves. 2. **Which products left that batch and in what quantity** — Without it nothing can be bounded forwards. 3. **Cleaning between batches, where it separates two origins** — It is what supports the claim that they did not mix. 4. **And what went to each client, from which batch** — The last piece, and the first one asked for in an alert. > [!WARNING] > The two points that break the system from inside and appear in no record: **rework and trimmings**. Product re-entering the line, or offcuts gathered for another product, carry the origin of everything present at that moment. If that is not recorded, a «clean» batch can contain material from three others nobody logged — and on the day something has to be bounded, your calculation will be wrong without anyone knowing. > [!NOTE] > What health rules require in identification, records and separation in a cutting room is set by the applicable hygiene and traceability rules and by your authorisation's conditions. **Your quality manager or health authority settles that**; here we explain the grouping decision, which is yours and which determines everything else. **Do I have to trace by carcass?** Only where the product justifies it. By shift is standard and usually suffices. **What about reworked product?** Record it. It is what most often invalidates a scope calculation. **How long do I keep the records?** At least the life of the product despatched, with margin. ## Ejemplos **The cutting batch is weekly and an incident forces five days' production to be held.** - Switches to grouping by shift and records which carcasses enter each batch → The next incident is bounded to a few hours of work. **Trimmings from three different batches are reworked with nothing recorded.** - Logs the rework, stating which batches the material came from → The scope calculation describes what is actually in each box. **An alert arrives and nobody knows which clients received the affected batch.** - Records what went to each client, and from which batch, at despatch → Client notification goes out same-day instead of three days later. **The carcass arrives identified and the boxes leave without a reference.** - Ties each box to the cutting batch → The backward journey survives the cut. **Carcasses from several intakes are grouped into one batch.** - Records what went into each batch → You can say what came from where. **A client asks about one specific box.** - Checks that box's batch → You reach the holding of origin. --- --- id: KB-AL-025 url: https://app.codecontract.io/help/food-and-beverage/milk-from-several-farms-in-one-tank idioma: en categoria: sector-alimentacion subcategoria: lacteos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-004, KB-AL-018] citadoPor: [KB-AL-022] --- # Milk from several farms in one tank _The moment two farms share a tank they share a fate. The question is not whether to mix, but what is kept before mixing._ **Responde a:** traceability of milk from several farms · milk samples per farm · the tank mixes the collection · milk testing before discharge The collection route calls at six farms and fills a tanker. The moment the second discharges onto the first, there is no way to separate what each contributed. From then on the whole tanker is worth whatever the worst of the six is worth — and that is not a technical problem, it is why a sample is taken at every stop. ## What decides everything, and happens before mixing | Moment | What is decided there | | --- | --- | | **The sample at the farm** | **The only evidence of what each contributed** | | The rapid test before loading | Whether a problem gets in or stays out | | The record of which farms are on each tanker | Whether you can look back afterwards | | Discharge at the plant | From here the batch belongs to everyone | > [!IMPORTANT] > **An unidentified sample is worthless, and it is the commonest failure.** A sample that does not say which farm, which day and which collection is exactly as useful as not having taken one: when a result forces you to look back, you will not be able to attribute it to anyone and the cost gets shared among everyone on that tanker. Labelling the sample properly takes seconds and is the only thing separating an incident from a dispute. ## What is worth settling in advance 1. **What happens if a test fails with the tanker already loaded** — Decided beforehand, not at the plant gate. 2. **How long samples are kept and under what conditions** — They are worth little if badly stored, and that is discovered late. 3. **Who bears the cost and in which cases** — Written into the collection contract, not agreed in the heat of it. 4. **And how the affected farm is told** — Fast, because their next milking is already on its way. > [!WARNING] > An effect forgotten when designing routes: **collection order matters**. The farm loaded first cannot be tested separately once the tanker is full, and the last one conditions all the others. If a holding has a patchy history, putting it last does not improve it — but it completely changes how much milk is put at risk while checks run, and that is a decision genuinely in your hands. > [!NOTE] > Which controls and samples raw milk collection requires, how often and what limits apply is set by the applicable hygiene rules and by agreements with the industry. **Your quality manager settles that**; here we cover the organisational part: what is kept before mixing erases the origin. **Can I tell which farm a problem came from?** Only if that collection's sample is identified and properly stored. **What if the result arrives once the milk is processed?** Then the sample is the only thing that bounds it. Hence keeping it. **Is testing before loading worth it?** It is what decides whether the problem enters the tanker or stays out. ## Ejemplos **A result forces a look backwards and the samples do not say which farm they are from.** - Labels every sample with farm, day and collection at the moment of taking it → The incident is attributed to whoever it belongs to instead of shared among six. **A test fails with the tanker loaded and it gets decided at the plant gate.** - Writes down beforehand what happens in that case and who bears what → The decision is taken on criteria rather than with a lorry waiting. **A holding with a patchy history is first on the route.** - Reviews the collection order against risk → Less milk is put at risk while checks are carried out. **Two farms share a tank and there is no record of what went in first.** - Records each intake before mixing → The trace survives the blend. **An analysis comes back poor and affects the whole tank.** - Checks which farms made up that tank → You know who is affected and who is not. **Collection is noted on the delivery slip and gets lost.** - Captures the slip at the collection itself → The record does not travel in the cab. --- --- id: KB-AL-026 url: https://app.codecontract.io/help/food-and-beverage/manufacturing-for-someone-elses-brand idioma: en categoria: sector-alimentacion subcategoria: conservas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-006, KB-NO-024, KB-AL-028] citadoPor: [KB-AL-027] --- # Manufacturing for someone else's brand _You make it and someone else's name is on the jar. What to settle before the first run is who answers for what._ **Responde a:** private label manufacturing documentation · co-packing who is liable · i produce for another company what paperwork · contract manufacturing agreement food You produce for a company that puts its name on the label. Everything works until someone asks about a batch: then two companies point at each other, two incomplete archives appear, and a label that names only one of them. **Contract manufacturing** — You provide the process and often some of the raw materials; the client provides the brand, the recipe or the specifications, and does the selling. Documentarily it is two companies with two archives that have to fit together. ## What to divide up in writing before the first run | What | Usually belongs to… | What fails | | --- | --- | --- | | The product specification | The client | It changes by email and nobody versions it | | Raw materials and their suppliers | It depends, and that is the tangle | Each believes the other controls it | | Labelling and its claims | The client | You print it without being able to verify it | | **Production records** | **You** | **The only thing that can bound a batch** | > [!IMPORTANT] > **The production record is yours and is not handed over wholesale, but it must be consultable.** It is what protects you —showing what you did and how— and the only thing that bounds a problem to a few hours of line time rather than to the whole brand. A manufacturing contract that does not say which records you keep, for how long and how they are accessed leaves both parties blind on exactly the day sight is needed. ## The awkward conversation: who tells whom 1. **If you detect a problem** — Who you call, within what time, and who decides what happens. 2. **If the client detects it** — What information they give you and by when, so you can look. 3. **Who speaks to the authorities and the consumer** — Normally the brand owner, but it is worth writing down. 4. **And who bears the cost of a withdrawal** — What nobody wants to negotiate before, and everyone negotiates after, worse. > [!WARNING] > The commonest trap in these relationships: **the client changes the specification by email and production carries on with nothing updated**. An ingredient swapped, a new supplier, a different weight. Months later the product does not match its sheet and nobody knows from which batch it stopped matching. Every specification change needs a version, a date and the batch it applies from — and that is your work even though the decision is theirs, because it is your production record that will speak. > [!NOTE] > Which duties each party assumes when one company manufactures for another's brand, and who is named as responsible for the product, depends on food law and on what the contract says. **Your adviser settles that before the first run**; here we explain what that contract must say so that on the day of a problem there are not two companies looking at each other. **Do I have to hand my records to the client?** Consultable yes, handed over whole rarely. Agree it in writing. **Who appears as responsible on the label?** Normally whoever markets it, but that does not remove your records. **What if the client changes the recipe midway?** New version, date and the batch it applies from. Without that nothing can be bounded. ## Ejemplos **The client changes an ingredient by email and production continues on the old sheet.** - Versions every change with a date and the batch it applies from → You can say from when the product is the new one and from when it was the old. **A problem appears and both companies believed raw material control was the other's.** - Divides in writing who controls what before the first run → There is an owner for each item instead of two incomplete archives. **Product must be withdrawn and nobody had discussed who bears the cost.** - Writes down who notifies, who decides and who pays, before starting → The withdrawal happens while the cost is argued, rather than the reverse. **The brand owner asks for documentation never agreed.** - Writes down what each side provides before the first run → The request does not arrive as a surprise. **An ingredient changes and the brand owner is unaware.** - Communicates the change before producing → The label on their brand stays true. **An end customer complains and it reaches the maker.** - Checks that run's file → You answer with what was produced. --- --- id: KB-AL-027 url: https://app.codecontract.io/help/food-and-beverage/selling-under-your-brand-what-someone-else-makes idioma: en categoria: sector-alimentacion subcategoria: retail audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-026, KB-AL-003, KB-AL-031] citadoPor: [KB-AL-028] --- # Selling under your brand what someone else makes _Putting your name on the pack puts you in front. To whoever asks, the maker stands behind you, not in your place._ **Responde a:** own brand who is responsible for the product · i sell another maker's product under my brand · private label distributor liability · what documentation to require from my co-packer You commission the product, choose the packaging and put your name on it. Commercially it is a margin decision; documentarily it is a change of position: **you move from selling someone else's product to presenting a product as yours**, and whoever asks will ask you. ## What changes compared with distributing someone else's brand | Situation | Who is asked first | What you need to hold | | --- | --- | --- | | You sell the maker's brand | The maker | Your delivery notes and little else | | **You sell under your brand** | **You** | **The product's whole file** | | You import it yourselves | You | That, plus the customs paperwork | > [!IMPORTANT] > **Your name on the pack is what puts you in front, and it cannot be delegated backwards.** You can require whatever you like of the maker and pass on what is fair, but the one receiving the question is you, and the one who must be able to answer on the spot is you. A file consisting of «we'll ask the manufacturer» takes days to fill, and days is exactly what you do not have. ## What to require from the maker, travelling with every run 1. **The product sheet as actually manufactured, versioned** — Plus a commitment to notify before changing anything. 2. **Which batch they made and when, with every delivery** — Without it you cannot bound anything: you will only know when it reached you. 3. **The data supporting what your label says** — Everything the pack claims, you are claiming. 4. **And who to call at their company on a Sunday** — Product problems do not wait for Monday. > [!WARNING] > The most neglected point and the one that stings most when it lands: **you write the label and someone else makes the product**. Every claim on the pack —origin, ingredients, properties, absences— is a claim you are making about a process you do not control. Before printing, each claim needs data from the maker behind it; and when the maker changes something, that claim stops being true without anyone touching the label. > [!NOTE] > Who is named as responsible for a food, what putting your own brand on it entails and which specific duties come with it depends on food and labelling law. **Your adviser settles that before launching the brand**; here we explain the change of position almost nobody prices in when deciding. **Does my contract with the maker protect me?** It lets you pass on cost; it does not move you out of the front line. **Do I have to hold the file myself?** At minimum be able to consult it immediately. «I'll ask» is not an answer. **What if the maker changes something?** Your label may stop being true. Require prior written notice. ## Ejemplos **A client asks about a batch of your brand and it has to be requested from the maker.** - Requires every delivery to arrive with its manufacturing batch and date → The question is answered on the spot instead of in two days. **The maker changes an ingredient's origin and the label still says the old thing.** - Agrees prior written notice of any change affecting the label → What the pack claims stays true after the change. **A problem arises on a Sunday and there is nobody to call at the factory.** - Agrees an operational contact with a phone number, out of hours included → The response starts on Sunday rather than Monday morning. **The maker changes something and the label stays the same.** - Asks them to communicate any change before producing → The label with your name stays true. **A customer asks and the maker has to be phoned.** - Keeps their documentation in your own file → You answer without depending on them. **The maker stops working with you.** - Keeps its own copy of what was received → The history does not leave with them. --- --- id: KB-AL-028 url: https://app.codecontract.io/help/food-and-beverage/who-prints-the-pack-and-what-it-says idioma: en categoria: sector-alimentacion subcategoria: packaging audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-014, KB-AL-027] citadoPor: [KB-AL-026] --- # Who prints the pack and what it says _The printer answers for the material and for printing what they were sent. That what was sent is true is the sender's problem._ **Responde a:** who is liable for a label error · food packaging printer documentation · declaration of compliance for packaging · printing error in food labelling Two responsibilities live on a label and almost nobody separates them: **the material it is printed on** and **what is printed**. The first belongs to whoever makes the packaging; the second to whoever sent the artwork. When something goes wrong, the trouble is that both get argued as if they were one. ## Who answers for what | What fails | Whose it usually is | | --- | --- | | The material is not fit for food contact | The packaging maker's | | Ink migrates or the material fails in process | The maker's, if they knew the use | | **The text says something untrue** | **Whoever sent the artwork** | | An old artwork version was printed | Whoever failed version control. Usually a tangle of both | > [!IMPORTANT] > **The fourth row happens most often and is the only one avoidable at no cost: artwork version control.** Artwork circulating by email under names like «final label», «final label good» and «final label v2» reaches the printer in the wrong version — discovered with twenty thousand units made. One version, one date and one written approval before each run solves the whole thing. ## What to ask the packaging maker for 1. **Their declaration of compliance for food contact** — Referring to the material supplied to you, not to their catalogue. 2. **That they know your intended use** — Hot, frozen, fatty, acidic: it changes whether the material works. 3. **Notice if they change material or supplier** — A silent change invalidates what you have on file. 4. **And a record of which run they supplied and when** — It is what bounds things if a material problem appears. > [!WARNING] > A case settled in a minute that costs thousands when it is not: **the printer cannot check whether what you send is true, and it is not their job**. If the artwork names an ingredient no longer used, a weight that is wrong or a claim you cannot support, it will be printed exactly and perfectly. Checking the text is true happens before the file is sent, and only whoever knows the product can do it: you. > [!NOTE] > What requirements a food-contact material must meet, what documentation must accompany it and which label statements are mandatory is set by the applicable rules. **Your adviser or quality manager settles that**; here we cover the practical split that avoids arguing with the run already printed. **Is the maker's generic declaration enough?** It must refer to the actual material supplied and to your use. **Who pays for a mis-printed run?** It depends where the failure was: the artwork or the printing. **How do I avoid printing an old version?** One version, one date and one written approval before each run. ## Ejemplos **Artwork named «final label good» reaches the printer and was not the latest.** - Approves a dated version in writing before each run → What was approved gets printed, not whatever last circulated by email. **The packaging maker changes material without notice.** - Agrees change notification and asks for a declaration covering the supplied material → What is on file still describes the packaging actually in use. **The label claims something the product stopped containing two runs ago.** - Checks every pack claim against the product sheet before sending artwork → The pack says what the product is — the one thing the printer cannot check. **Text that is no longer correct is sent to print.** - Reviews the final artwork before sending → Reprinting a whole run is avoided. **The printer keeps the version they printed and you do not.** - Keeps each final artwork with its date → You know what was printed and when. **An ingredient changes with packaging already printed.** - Checks how much packaging stock is affected → The decision is taken knowing the volume. --- --- id: KB-AL-029 url: https://app.codecontract.io/help/food-and-beverage/the-one-who-harvests-and-makes-the-first-sale idioma: en categoria: sector-alimentacion subcategoria: pesca audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-017, KB-AL-022] citadoPor: [KB-AL-030, KB-AL-031] --- # The one who harvests and makes the first sale _The work happens where there is no office and no signal. What is not recorded there never appears anywhere later on its own._ **Responde a:** what to record at first sale · documentation for a catch or a harvest · how to record output without an office · asked for the origin of what i sold months ago Your work happens at sea, in the field or on the hill, and ends when the product changes hands for the first time. **You are the only point in the whole chain that truly knows what happened**, and also the one with the fewest means to write it down: there is no desk, often no signal, and the reasonable priority at that hour is to unload and sell, not to fill anything in. ## Why this position weighs more than it looks | What is recorded here | Who will use it | If it is not recorded | | --- | --- | --- | | What it is and how much | The buyer, on paying | It gets argued on the spot | | Where it came from | The whole chain, later | **Nobody can reconstruct it** | | When it was taken | Whoever processes or sells it | It gets estimated, which is not the same | | **How it was handled** | **Whoever answers for it** | **It stays in your memory** | > [!IMPORTANT] > **Everything the chain will say about this product for the rest of its life is decided at this moment and cannot be corrected afterwards.** A packer can redo a label, a distributor can request a certificate again, a supermarket can change supplier. You cannot go back and record where something came from once it has been sold: that fact existed for a few hours, in one place. ## What works when there is no office 1. **Record it there and then, even on a phone** — What is left for the evening is done from memory, or not at all. 2. **A photo counts as a record** — Of what goes out, what gets signed, what is handed over. 3. **It must work without signal and send later** — If it needs coverage, the day there is none the record is lost. 4. **And not depend on one person or one handset** — It is the commonest failure and the quietest. > [!WARNING] > The specific risk in this position is not breaching anything: **it is being unable to show what you did do**. The work is done well, things are handled properly, and months later a question arrives that can only be answered with a document nobody produced. The honest answer —«we did it, I just did not write it down»— carries exactly the same documentary weight as not having done it, and that is what is hardest to accept from this seat. > [!NOTE] > What must be recorded and declared at a first sale, within what deadlines and to whom **depends on the activity, the species or crop and the country, and is settled by your competent authority, your producers' organisation or your adviser**. Here we cover the practical part: how to evidence what you do in conditions where writing is the last thing you feel like doing. **Does a photo count as a record?** For a great many things yes, and it is infinitely better than memory. **What if there is no signal where I work?** Record it at the moment and send it on return. The moment is what cannot fail. **Should I keep a copy of what I hand the buyer?** Yes. The buyer keeps theirs with themselves in mind, not you. ## Ejemplos **What is taken gets written up at night, from memory.** - Allows recording at the moment from a phone → The data is captured while it is still accurate. **There is no signal where the work happens.** - Stores what was captured and sends it when signal returns → Nothing is lost by working out of network range. **Months later the origin of a sold consignment is queried.** - Keeps each delivery with its date and destination → There is an answer instead of an estimate. **The buyer keeps the only copy of the document.** - Captures and keeps your own copy of what was handed over → The producer stops depending on the buyer's archive. **Everything sits on one person's phone.** - Centralises records away from a single device → A lost handset stops meaning a lost archive. **The same information is rewritten for every buyer.** - Reuses what is already recorded on each delivery → Admin does not multiply by the number of customers. --- --- id: KB-AL-030 url: https://app.codecontract.io/help/food-and-beverage/buying-from-a-hundred-small-producers idioma: en categoria: sector-alimentacion subcategoria: mayoristas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-029, KB-AL-012] citadoPor: [KB-AL-031] --- # Buying from a hundred small producers _Your suppliers have no quality department and no appetite for paperwork. And still, what you sell rests on what they record._ **Responde a:** onboarding small suppliers with no back office · how to request documentation from small producers · traceability when buying from many suppliers · my suppliers do not send the paperwork You buy from a hundred, two hundred or a thousand small producers. Many are excellent at what they do and **none has anyone dedicated to sending you paperwork**. Your position aggregates: everything of theirs comes through your door and goes out under your name to customers who do have a quality department and do know exactly what to ask for. ## The asymmetry that defines this position | Upstream | You | Downstream | | --- | --- | --- | | A hundred small suppliers | A single link | Large, demanding customers | | No administrative structure | Yours | Theirs, plus auditors | | Send what they can | You have to complete it | Ask for everything, in writing | | **Ask you not to complicate things** | **You are in the middle** | **Ask that nothing be missing** | > [!IMPORTANT] > **Asking for a lot and asking clearly are different things, and confusing them is the classic error in this position.** A small producer does not stop sending paperwork out of unwillingness: they stop because they cannot tell which of the four things you asked for is still missing, cannot find the email that explained it, and their season is in its worst week. A short, specific list with somewhere to upload it moves the response rate more than any amount of chasing. ## What works with suppliers who have no back office 1. **Ask for little and ask the same way every time** — The short list that gets met beats the complete one that gets ignored. 2. **Uploading must be easier than replying to an email** — If it requires registering for something, half of them will not. 3. **Chase without a person doing it** — With a hundred suppliers, chasing by hand is a full-time job. 4. **And see at a glance who is current and who is not** — Because the buying decision happens before anyone opens the folder. > [!WARNING] > The moment this position gets hard is **the season**. Exactly when the volume arrives, when you must decide quickly who to buy from, and when your suppliers are busiest, is when documentation is least looked at and most is bought. What is decided in those six weeks is what will sit in your batches for the rest of the year. Reaching the season with suppliers already current is, in practice, the entire job. > [!NOTE] > What documentation you must require from your suppliers, which controls belong to each link and what traceability duties apply **depends on the product and the country, and is settled by your adviser or the competent body**. Here we cover the operational part: how to ask many at once and how to know, without opening anything, who is ready for the season. **What if a supplier sends nothing?** That is a buying decision, not an administrative one. What matters is knowing before you buy. **Can I ask less of the smallest ones?** What you ask for sets what you can say later. That is your call, made knowingly. **How do I do this without dedicating a person?** Have the request and the reminder go out on their own. With a hundred suppliers there is no other way. ## Ejemplos **A hundred suppliers email their papers whenever they can.** - Requests specific documents with somewhere to upload them → What arrives is comparable and needs no sorting. **Chasing the stragglers takes one person full time.** - Chases automatically until the document arrives → That person buys instead of nagging. **The season starts and nobody knows which suppliers are current.** - Shows the status of every supplier at once → Buying happens knowingly rather than being reviewed afterwards. **A producer cannot tell which of the four documents is missing.** - Shows them their own list of what is outstanding → The reply arrives without a call to explain it. **Documentation lapses unnoticed until the audit.** - Warns about expiries before they happen → The supplier renews before it becomes a problem. **A large customer asks for a supplier's complete file.** - Gathers everything for each supplier in one file → It is handed over without reassembling anything. --- --- id: KB-AL-031 url: https://app.codecontract.io/help/food-and-beverage/selling-direct-what-you-produce idioma: en categoria: sector-alimentacion subcategoria: retail audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-029, KB-AL-030, KB-AL-023] citadoPor: [KB-AL-027] --- # Selling direct what you produce _With no middlemen nobody asks you for paperwork — until someone asks who will not accept «I make it myself»._ **Responde a:** selling direct to consumers documentation · farm gate sales what do i need · market stall or own shop paperwork · a customer asks for certificates and i have none You produce and sell it yourself: at the farm, at a market, in your own shop or online. **You have skipped the entire chain**, and with it everyone who, on the normal route, would have asked you for paperwork one at a time. That has an obvious upside —margin and direct contact— and an effect that takes a while to surface: nobody has been teaching you what you need to hold. ## When the first one who does ask turns up | Who | What they want | If you do not have it | | --- | --- | --- | | A private customer | To know what they are buying | It is settled by talking | | A restaurant | To evidence who they buy from | The customer falls through | | A shop or a group | A complete file | No account is opened | | **An inspection** | **Whatever applies** | **It is not settled by talking** | > [!IMPORTANT] > **The jump is not from selling little to selling a lot: it is from selling to people to selling to companies.** The day a restaurant, a shop or a platform buys from you, you enter somebody else's chain — and that chain has requirements that do not scale down to your size. That day always arrives earlier than expected, usually as a good opportunity that needs answering within a week. ## What is worth having before you need it 1. **Knowing what you sell, in what quantity and to whom** — Even at the most basic level: it is the first thing you will be asked. 2. **Keeping what you already generate** — Records, invoices, analyses. There is almost always more than it seems. 3. **Holding it in one place and not five** — The day it has to be sent, it gets sent; it does not get hunted for. 4. **And knowing what expires** — What renews once a year is forgotten once a year. > [!WARNING] > What gets lost through having no paperwork is rarely a penalty: **it is customers who never become customers**. A restaurant wants to buy from you, asks for something, you do not have it to hand, you say you will send it next week — and that week they buy from someone else. There is no dispute, no complaint and no way for you to learn it happened. It is the quietest loss in this position and the only one avoided by two afternoons of work. > [!NOTE] > What a direct sale requires exactly —registrations, authorisations, labelling, premises conditions— **depends on the product, the volume, the channel and the country, and is settled by your competent authority or your adviser**. Here we cover what is common to all of it: how to keep what you already have to hand and current, so you can answer the day someone asks. **If I sell very little, do I need anything?** It depends on the product and channel, and your authority settles that. Keeping what you already generate in order does not depend on volume. **What will a restaurant ask me for?** Usually less than you fear, but they want it that week. **Is it worth doing before anyone asks?** That is exactly the moment when it costs little and is worth something. ## Ejemplos **A restaurant asks for documentation and it is not to hand.** - Gathers what is already generated in one place → You answer that week instead of the next. **Records are split across notebooks, email and a phone.** - Keeps everything in a single file → What exists is visible without searching three places. **An annual document expires and nobody remembers until it is needed.** - Warns before it falls due → Renewal happens with time to spare. **Every new customer asks for the same thing and it starts from scratch.** - Reuses the same file for each request → The second customer costs far less than the first. **There is no record of who was sold what.** - Records deliveries with date and recipient → There is an answer if anyone asks later. **Starting to sell to businesses looks like a different world.** - Shows what is missing for the file to be complete → The step is taken from a list rather than a hunch. --- --- id: KB-CS-007 url: https://app.codecontract.io/help/food-and-beverage/food-supplier-traceability idioma: en categoria: sector-alimentacion subcategoria: distribucion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-001, KB-CF-003, KB-AL-016] citadoPor: [KB-IC-002, KB-NO-004, KB-CS-018, KB-AL-001, KB-AL-006] --- # Food supplier traceability _Being able to say within an hour where each batch came from and under which certificates._ **Responde a:** food supplier traceability · supplier health certificates · ifs brc audit documentation · product recall traceability In food the question always arrives the same way and always in a hurry: where did this batch come from and what certificates did that supplier hold that day. Answering in an hour rather than two days is the difference between a targeted recall and a general one. **En corto** - What matters is what was valid on the batch date, not today. - Sector certificates expire, and with them the validity of what they covered. - A history with trusted dates answers by itself; a filing cabinet does not. ## What you must be able to show | Question | What answers it | | --- | --- | | Who supplied this batch? | The supplier's case, with its date | | Were they approved that day? | The history, not the current status | | Which certificates did they hold? | The documents valid on that date | | When did they expire? | The recorded expiry dates | > [!IMPORTANT] > The question is always in the past tense. A system that only reports today's status is no use in a recall: you must be able to say what was true on 14 March. ## For sector audits Food certification schemes ask for exactly this: dated documentary evidence that each supplier was approved when they supplied. It is the same thing a recall needs, so it is built once and serves both. > [!NOTE] > Marking health certificates with their expiry turns approval from an annual snapshot into a status that is maintained. **Can it be queried by batch?** If the batch is linked to the supplier's case, yes. **What about my suppliers' suppliers?** Requested as documentation inside your direct supplier's case. **How long must it be kept?** Whatever your certification requires; set in the retention policy. ## Ejemplos **A packer receives a health alert about a raw material.** - Locates the batch's supplier - Checks which certificates were valid on that day → Narrows the recall to two batches instead of a month's production. **A client asks for a batch's origin and it takes two days.** - Checks the batch's file → The answer comes out in minutes. **A supplier's certificate expired and their product is still in stock.** - Records validity on receiving each certificate → The warning arrives before the material is used. **The trace breaks between goods-in and production.** - Ties the received consignment to the batch produced → The backward journey is complete. **Each person keeps their own suppliers' certificates.** - Gathers everything in one place → The answer does not depend on who is in. **Customers who received a batch have to be warned.** - Checks what went out of that batch and to whom → Those affected are warned rather than the whole base. --- --- id: KB-CS-010 url: https://app.codecontract.io/help/manufacturing/machinery-and-equipment-certificates idioma: en categoria: sector-industria subcategoria: componentes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-003, KB-CF-002] citadoPor: [KB-CS-017, KB-CS-021, KB-IU-001, KB-LG-004, KB-IU-004, KB-IU-006] --- # Machinery and equipment certificates _Tracking paperwork attached to a machine rather than a person._ **Responde a:** machinery document control · equipment conformity certificates · periodic machine inspections · work equipment documentation Machinery documentation has a wrinkle that makes it harder than people's: the machine moves. The same crane is on one site this month and another the next, and its paperwork has to travel with it. **En corto** - The case attaches to the equipment, not to the site it is on today. - Nearly everything expires: inspections, insurance, the operator's training. - Whoever receives the machine has to be able to check on the spot. ## The three levels to cross-check | Level | Documents | Expires | | --- | --- | --- | | The equipment | Declaration of conformity, manual, marking | No, unless modified | | Its maintenance | Periodic inspections, latest checks | Yes, and it is the most forgotten | | Whoever operates it | Specific training, authorisation to use | Yes | > [!IMPORTANT] > A machine having its certificate does not authorise anyone to use it. The cross-check between machine and person is where industrial document control fails, and it is exactly the one examined after an accident. ## What changes versus tracking it by site If the case belongs to the site, every transfer means rebuilding it and the machine arrives with no paperwork. If it belongs to the equipment, it travels with it: assign it to the new site and its documentary status follows, with its dates. > [!WARNING] > Hired equipment arrives with the hire company's documentation, expiring on their schedule rather than yours. Mark it the same way: hired equipment with a lapsed inspection is your problem while it is on your site. > [!NOTE] > Setting inspections to warn 60 days out leaves time to schedule the downtime. Fifteen does not, and the machine sits idle waiting for a technician. **Can I have one case per serial number?** Yes, and that is what lets you follow it between sites. **What about small equipment?** Items that neither expire nor need training do not need a case; forcing it fills the system with noise. **Does it serve for a labour inspection?** It is exactly the cross-check they ask for: equipment in order and an authorised operator. ## Ejemplos **A manufacturer tracks machine documentation by site and loses it on every transfer.** - Moves each machine to its own case, by serial number - Marks inspections and training with expiry dates → The machine arrives at the new site with its documentary status current, and the supervisor checks it from a phone. **A machine is bought without its documentation.** - Requests it on the purchase order, before paying → It is asked from the only position of leverage. **An item of plant's documentation sits in a drawer.** - Captures and stores it with the equipment → It is found where the machine is. **Calendar inspections get forgotten.** - Records expiries per item of plant → The warning arrives before the date. **A client asks for the machinery certificates.** - Checks each item's file → It is handed over without reassembling anything. **Equipment is sold and its documentation does not travel with it.** - Hands over the complete file with the machine → The buyer receives what covers it. --- --- id: KB-CS-021 url: https://app.codecontract.io/help/manufacturing/manufacturing-and-industrial-supply idioma: en categoria: sector-industria subcategoria: componentes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-010, KB-NO-001] citadoPor: [KB-IU-001, KB-CS-026, KB-CS-027, KB-IU-002] --- # Manufacturing and industrial supply _Material certificates, customer approvals and traceability by batch._ **Responde a:** material quality certificate · industrial supplier approval · heat number traceability · technical documentation for industrial customer An industrial manufacturer sits in the middle of a chain: it receives certificates from suppliers and has to issue its own to customers. What almost always breaks is the link between the two: the material certificate is there, but there is no record of which delivered part it belongs to. ## The three modules in the chain | What | Module | Direction | | --- | --- | --- | | Supplier material certificates and test reports | Trackline | Upstream | | Technical agreements and specifications | Consigne | Both directions | | Manufacturing record for a batch | SmartCheck | Downstream, where it may be disputed | > [!IMPORTANT] > Keeping the certificate is not enough: you must be able to say which certificate belongs to which delivery. When a customer complains about a part from two years ago, the question is not "do you have certificates?" but "which one was this part's?". ## Frameworks cited Product marking and declaration of conformity, work equipment requirements, quality management systems, and — depending on what you make — sector-specific rules and ecodesign with its product passport. What applies depends on the product and the destination market; confirm with your adviser or notified body. > [!WARNING] > If you export outside the EU or import components, origin documentation takes longest to arrive and gets asked for most afterwards. Requesting it before you need it is the only way to have it. > [!NOTE] > If a customer re-approves you annually with the same questionnaire, build it as a process. What they ask changes little between editions. **Can I link a certificate to a specific batch?** Yes, and that is what lets you answer a claim in minutes. **Does it serve for a customer audit?** It is exactly what gets shown: certificate, date and which delivery it belongs to. **What about tests done by an external laboratory?** They go into the case as documentation, with their date and expiry if any. ## Ejemplos **A manufacturer receives a claim about a part supplied two years ago.** - Locates the batch and its linked material certificate → Answers within the hour with the exact certificate instead of absorbing the cost for lack of proof. **A client audits with two weeks' notice.** - Reviews the file before it lands → The gaps close with time to spare. **Supplier documentation is held per person.** - Centralises the files in one place → The answer does not depend on who is in. **A supplier certificate expires.** - Records expiries per supplier → The warning arrives before the next order. **A client asks for the traceability of one specific supply.** - Checks that delivery's file → You answer per delivery. **Every audit is prepared from scratch.** - Keeps the file current through the year → The second audit costs a fraction. --- --- id: KB-IU-001 url: https://app.codecontract.io/help/manufacturing/document-control-in-manufacturing idioma: en categoria: sector-industria subcategoria: maquinaria audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-021, KB-CS-010] citadoPor: [KB-IU-004, KB-IU-005, KB-IU-006] --- # Document control in manufacturing _You sit mid-chain: you receive certificates and have to issue your own._ **Responde a:** industrial document control · manufacturing supplier certificates · technical manufacturing documentation · where to start with factory document control A manufacturer has the documentary problem in both directions at once: it receives certificates from suppliers and has to issue its own to customers. Almost everything that breaks sits in the link between those two directions. ## The three layers, outside in | Layer | What documentation | What breaks | | --- | --- | --- | | Suppliers | Material certificates, test reports, approvals | They expire and nobody looks | | Equipment and people | Conformity, inspections, operator training | The cross-check between machine and operator | | Customers | What they ask of you: questionnaires, traceability | It arrives on a short deadline and depends on the other two | > [!IMPORTANT] > The customer layer cannot be handled quickly if the first two are loose. A questionnaire asking for material origin with a two-week deadline cannot be answered unless you started asking your suppliers earlier. ## Where to start **En corto** - With what expires: it is what can blow up unannounced. - With linking each certificate to the specific delivery, not merely storing it. - With the customer who audits you most, building their questionnaire as a process. > [!WARNING] > Storing the certificate is not enough: you must be able to say which delivery it belongs to. When a customer complains about a part from two years ago, the question is not whether you hold certificates but which one was that part's. > [!NOTE] > Each industrial branch adds its own — automotive demands batch traceability, chemicals demand current composition — but these three layers are common to all. **Do I start with suppliers or customers?** Suppliers. Without that, the customer side cannot be answered. **Does it work if we make to order?** Especially: each order is a case with its traceability. **What if our suppliers are outside the EU?** That is where origin documentation takes longest and where it pays to start earliest. ## Ejemplos **A manufacturer gets a sustainability questionnaire with a two-week deadline and lacks the data.** - Answers what it has and states when the rest will come - Launches an origin request to its suppliers → Keeps the customer without committing to invented figures, and answers the next questionnaire in an afternoon. **Each department keeps its documentation separately.** - Centralises into a file per product or batch → There is one picture. **The trace breaks between production and despatch.** - Ties the batch produced to the outgoing delivery note → The batch is followed to the customer. **A client asks about a supply from a year ago.** - Keeps the file with its date → You answer without reconstructing. **Supplier certificates expire without warning.** - Records expiries per supplier → The warning arrives before the material is used. **A review asks for evidence of a control.** - Shows the record of real operations → The control moves from assertion to evidence. --- --- id: KB-CS-026 url: https://app.codecontract.io/help/manufacturing/chemicals-and-plastics-processing idioma: en categoria: sector-industria subcategoria: quimica audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-CS-021] citadoPor: [KB-IU-003] --- # Chemicals and plastics processing _Safety data sheets that change, substances that get restricted, and customers who ask._ **Responde a:** updated safety data sheets · restricted substances in my products · composition declaration to customer · chemical compliance supplier documentation In chemicals and plastics, documentation does not expire on a date: it expires because the rules change. A substance usable today may be restricted, and then you have to know which of your products contained it — and you only know if you asked beforehand. ## The three modules | What | Module | Why there | | --- | --- | --- | | Supplier safety data sheets and composition | Trackline | They come from outside and update without notice | | Confidentiality agreements over formulations | Consigne | Before sharing anything technical | | Production and batch control records | SmartCheck | When a specific batch may be disputed | > [!IMPORTANT] > The safety data sheet is updated by the supplier when something changes, and they do not always send it. Marking it for annual review is the minimum: working from a four-year-old sheet is working from information that may have stopped being true. ## Frameworks cited Chemical substance registration, evaluation and authorisation, classification and labelling, safety data sheets, substance restrictions in articles, and — depending on the end product — packaging, food contact or ecodesign rules. The exact scope depends on your activity and volumes; confirm with your adviser. > [!WARNING] > When a customer asks whether one of your products contains a specific substance, the deadline is usually short and the answer depends on sheets held by your supplier. If you have not requested them beforehand, you will not make it. > [!NOTE] > Confidentiality agreements signed before sharing formulation avoid the perennial problem: technical information emailed to someone who later changes employer. **Can I find which products use a substance?** If composition has been requested and stored per reference, yes. Otherwise it means asking supplier by supplier. **How often should sheets be renewed?** Annually at minimum, and whenever the supplier changes formulation. **Does it help answer a customer?** That is exactly the point: answering with a document and a date, not from memory. ## Ejemplos **A processor is asked whether a restricted substance is in its products, with a ten-day deadline.** - Checks the compositions already requested per reference → Answers in two days with documents instead of having to ask thirty suppliers. **A product's safety data sheet expires.** - Records validity on receipt → The warning arrives before the next shipment. **A client asks for one specific product's sheet.** - Checks that reference's file → You answer without phoning the supplier. **The supplier changes the formulation and nobody knows.** - Asks them to communicate any change → The change arrives before the question. **The documentation travels with the goods and gets lost.** - Also carries it accessible from a phone → A lost paper stops halting the job. **A raw material problem must be contained.** - Checks which production runs used it → Scope narrows to what is affected. --- --- id: KB-CS-027 url: https://app.codecontract.io/help/manufacturing/automotive-suppliers idioma: en categoria: sector-industria subcategoria: automocion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-021, KB-NO-004] citadoPor: [KB-CS-032] --- # Automotive suppliers _The most demanding customer you will have, and the one that audits most._ **Responde a:** documentation for an automotive manufacturer · automotive supplier audit · automotive quality standard documentation · tier 1 customer requirements Automotive is where documentary demands bite hardest, for one reason: a defective part can end in a recall campaign covering thousands of vehicles. The whole documentary system is designed around that. ## What you will be asked for, and what handles it | What they ask | Module | Frequency | | --- | --- | --- | | Documentation from your own suppliers | Trackline | Continuous, with expiries | | Quality and confidentiality agreements | Consigne | At onboarding and on every change | | Batch traceability back to material | Trackline + SmartCheck | Per delivered batch | | Responses to questionnaires and audits | Trackline | Annual or per project | > [!IMPORTANT] > Upstream traceability is what decides the scope of a recall. If you can say exactly which material batches went into which delivered parts, the campaign narrows; if not, it is scoped by dates and everything from that period is included. The difference is an order of magnitude in cost. ## Frameworks cited Sector-specific quality management standards, each manufacturer's particular requirements, and — across the board — supply chain due diligence and materials and substances rules. The concrete requirements come from the customer and your certification body. > [!WARNING] > One manufacturer's requirements are not another's, and they usually arrive contractually. If you supply three, you will have three different questionnaires asking almost the same things — building them as separate processes and reusing answers is the only thing that makes this sustainable. > [!NOTE] > Keeping each completed questionnaire with its date and source turns next year's into a review rather than a project. **Can I reuse answers between customers?** The answers yes; the format usually not. The saving is still there. **What if a supplier of mine gives no traceability?** That is your risk, not theirs: you are the one answering to the manufacturer. **How long must it be kept?** Periods in this sector tend to be long; confirm them in your contracts. ## Ejemplos **A component supplier receives a field incident and is asked to scope the affected batches.** - Checks which material batches went into each delivery → Scopes it to 3 batches instead of three months of production, and the campaign costs a fraction. **The client demands documentation per part and it is handled manually.** - Ties each part to its batch and file → The trace exists without extra work. **A process change never reaches the client.** - Communicates the change before applying it → The relationship does not break over a surprise. **A client audit arrives at short notice.** - Keeps the file current through the year → Preparation is a review. **A supplier changes and nobody reviews their documentation.** - Launches onboarding on the first order → No supplier gets in without a file. **A problem with a part must be contained.** - Checks which batches carry it and where they went → Those affected are warned. --- --- id: KB-CS-029 url: https://app.codecontract.io/help/manufacturing/renewables-and-energy-efficiency-projects idioma: en categoria: sector-industria subcategoria: renovables audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-017, KB-CS-006] citadoPor: [KB-CN-002, KB-CS-037] --- # Renewables and energy efficiency _Subsidised projects, many subcontractors, and a claim submitted months later._ **Responde a:** grant justification documentation · solar installation documentation · subcontractors on renewable projects · installation certificate and commissioning A renewables project combines two things already hard on their own: construction with subcontractors, and a grant claim submitted when the work finished months ago and nobody remembers the detail. ## The three layers | Layer | Module | When it is needed | | --- | --- | --- | | Subcontractors and their documentation | Trackline | During the works | | Contract and client sign-offs | Consigne | At start and handover | | Evidence of execution | SmartCheck | During, not at claim time | > [!IMPORTANT] > A grant claim is prepared during the works or not at all. Photos, delivery notes and certificates gathered afterwards have two problems: half are missing, and what exists has no reliable date. Certifying as it happens costs minutes; reconstructing later costs weeks and sometimes cannot be done. ## Frameworks cited Electrical and installation regulations, commissioning and registration requirements before the competent authority, the conditions of each grant call, and — where there are works — contractor safety coordination. Justification requirements are set by each call; read it at the start, not at the end. > [!WARNING] > Grant calls tend to require documentation in very specific formats, on deadlines that are not extended. Losing a grant over a piece of paper is the most expensive way to learn this. > [!NOTE] > If you run many similar projects, the claim is nearly identical each time. Built as a process, it fills itself in as the work progresses. **Can I give the client access during the works?** Yes, read-only and scoped to their project. **What about the evidence the call requires?** Certify it as it happens, not at the end. **Does it work across several sites?** One case per project, with its subcontractors inside. ## Ejemplos **An installer loses part of a grant for lack of execution evidence.** - Certifies photos and delivery notes during the works - Builds the claim as a process from the start → The next project reaches claim time with everything gathered and dated, with nothing reconstructed. **An installation's documentation scatters after commissioning.** - Gathers it into the installation's file → Whoever maintains it finds what went in. **Calendar inspections get forgotten.** - Warns about each due date in advance → The calendar keeps itself. **The client asks you to evidence a period's output.** - Checks the records for that date → You answer from the archive. **A component is replaced and the documentation stays the same.** - Updates the file with every change → The paper describes what is installed. **A grant asks you to evidence the installation years later.** - Keeps the complete file with its date → The claim comes from the archive. --- --- id: KB-IU-002 url: https://app.codecontract.io/help/manufacturing/pharmaceutical-and-medical-devices idioma: en categoria: sector-industria subcategoria: farmaceutica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-021, KB-CS-028, KB-LG-014] citadoPor: [KB-IU-008] --- # Pharmaceutical and medical devices _Batch traceability, storage conditions and documentation that cannot be improvised._ **Responde a:** pharmaceutical batch traceability · pharma supplier documentation · good distribution practice documentation · medical device chain of custody In pharmaceuticals and medical devices everything explained in other sectors applies the same, only with no margin. Batch traceability is not good practice: it is the condition for recalling a product without recalling a year's production. ## What gets cross-referenced | What | With what | For what | | --- | --- | --- | | Each manufactured batch | The raw material batches that went in | Scoping a recall | | Each shipment | Its transport and temperature conditions | Proving they held | | Each supplier | Their qualification on the supply date | Answering an inspection | | Each person | Their current training on that date | Justifying who did what | > [!IMPORTANT] > The question is always in the past tense and always specific: which raw material went into batch X, under what conditions did it travel, and who was qualified that day. A system reporting only today's status answers none of the three. ## What must be provable with no margin **En corto** - That records were not filled in afterwards. - That storage conditions held for the whole journey. - That whoever signed a release was authorised to sign it that day. > [!WARNING] > Certifying records periodically matters more here than in any other sector: an editable temperature or process record does not count as evidence before an authority, however well kept. ## Frameworks cited Good manufacturing and distribution practices, traceability and serialisation requirements, and — for medical devices — the specific regulation with its technical documentation and post-market surveillance. The exact scope and required validations are confirmed by your technical lead or regulatory adviser; this help centre replaces neither. > [!NOTE] > If you work in this sector you probably already have a validated system. What is explained here fits as a documentary layer over suppliers and third parties, not as a replacement for your quality system. **Does it replace my quality system?** No, and it should not try. It covers the documentary relationship with third parties. **Does it serve for an inspection?** Dated records and per-supplier history are what is asked for. **What about validation?** Check with your technical lead before using it for anything critical. ## Ejemplos **A distributor must scope an alert on a batch from fourteen months ago.** - Checks which source batches went in and under what conditions they travelled → Narrows it to two shipments instead of a whole quarter of dispatches. **A process change is applied before being documented.** - Records the change before applying it → The file describes what is done. **A batch needs documents from three departments.** - Gathers them in the batch's file → Release does not wait on searching. **A review asks about a batch from two years ago.** - Keeps the file with its date → You answer from the archive. **Supplier documentation expires with material in stock.** - Records expiries per supplier → The warning arrives before producing with it. **A deviation is resolved and the basis is not recorded.** - Records the decision and who took it → The deviation is explicable afterwards. --- --- id: KB-IU-003 url: https://app.codecontract.io/help/manufacturing/textiles-and-the-supply-chain idioma: en categoria: sector-industria subcategoria: textil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-004, KB-CS-026] citadoPor: [KB-IU-010, KB-IU-029] --- # Textiles: the chain nobody sees end to end _Several countries, several links, and customers asking about all of them._ **Responde a:** textile traceability · textile supplier documentation · social audit of suppliers · raw material origin textiles Textiles have the longest and least visible chain of any industrial sector: between fibre and garment there are often four or five companies across three countries, and whoever sells the garment rarely knows more than one. ## What you will be asked for, by difficulty | Level | What is asked | How hard to obtain | | --- | --- | --- | | Your direct supplier | Company data, certifications | Easy | | Garment composition | Technical data sheet | Easy | | Fabric origin | Traceability one link back | Hard | | Fibre origin | Traceability to the start | Very hard, and the most requested | | Labour conditions in the chain | Third-party audits | Depends who audits | > [!IMPORTANT] > The last two levels are not obtained by asking with a two-week deadline. If a customer requires them contractually, the real conversation is with your direct supplier about whether they can reach that far — and that conversation is best had before signing the customer contract. ## What you can control right now **En corto** - That every direct supplier has a case with what they do provide. - That there is a dated record of what you asked for and never arrived. - That any certification you use as an argument is current. > [!WARNING] > Be careful using a supplier's certification as a commercial argument without checking it is still valid. If it lapsed and you keep claiming it, the claim is yours. ## Frameworks cited Composition and care labelling, value-chain due diligence, substance restrictions in textile articles and — increasingly — ecodesign requirements and the product passport. What applies depends on your role and market; confirm with your adviser. > [!NOTE] > Starting to ask for origin before it is required is the only thing that works in this sector, because each link has to ask the next and that takes months. **What if my supplier does not know where the fibre comes from?** That is today's normal situation. Record that you asked and decide whether it changes anything commercially. **Does a third-party certification help?** A great deal, and you must check it is current and what exactly it covers. **Can I promise a customer full traceability?** Not before obtaining it. Promising and lacking it is worse than not offering it. ## Ejemplos **A brand promises fibre-level traceability in a tender and then cannot obtain it.** - Talks first to its direct supplier about how far they can reach - Offers what it can genuinely sustain → Wins the contract with a commitment it can meet, instead of losing it midway for lack of proof. **The chain has four links and only the first is known.** - Asks each supplier to declare theirs → The chain is known before it is asked about. **A client asks for the origin of one specific fabric.** - Checks that consignment's file → You answer per consignment. **Suppliers change every season.** - Launches onboarding on the season's first order → The file renews with the collection. **Certificates arrive in different formats.** - Requests specific documents to a single destination → What is received can be compared. **A certificate expires mid-production.** - Records expiries per supplier → The warning arrives before the order. --- --- id: KB-IU-004 url: https://app.codecontract.io/help/manufacturing/selling-machinery-and-the-documents-inside idioma: en categoria: sector-industria subcategoria: maquinaria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-001, KB-CS-010] citadoPor: [KB-NO-015, KB-IU-019] --- # Selling machinery: the documentation that goes with it _What you hand over with the machine stays with you for its whole working life._ **Responde a:** documentation delivered with a machine · manual and declaration of conformity handover · what papers accompany industrial equipment · machinery aftersales documentation When you hand over a machine you also hand over a documentary package that outlives the sale: the customer will need it at every inspection, every change of operator and every resale. And when they cannot find it, they will call you — five, eight or twelve years later. ## What goes with the machine | Document | What the customer uses it for | When they will ask you | | --- | --- | --- | | Declaration of conformity | Justifying they may use it | At their first inspection | | Instruction manual | Training whoever operates it | Every time the operator changes | | Maintenance documentation | Complying with inspections | Every year | | Critical component certificates | Facing an incident | At the worst moment | > [!IMPORTANT] > Handing it over with a signed receipt is what prevents the problem five years out. Without one, the conversation is "I never received that" and there is no way to close it — with one you resend and it is over. ## What is worth keeping on your side **En corto** - Which exact manual version went with which serial number. - The component certificates for that particular unit. - And who it was handed to, with the date. The first row is the most neglected. If the manual changes between units and there is no record of which one each carried, answering an aftersales query becomes guesswork. > [!WARNING] > If you modify a machine already delivered, the earlier documentation may have stopped describing what is installed. That is where a resale or an incident exposes a discrepancy nobody knew existed. > [!NOTE] > Handing over documentation digitally with a signed receipt also solves the resale case: the second buyer asks for it, and you can say exactly what was delivered and to whom. **Can I deliver it digitally only?** It depends what your product's regulation requires; check. **What if the customer loses the manual?** With the delivery record you know which version they had and resend it. **How long do I keep this documentation?** Machine working lives tend to be long; confirm with your adviser. ## Ejemplos **A manufacturer gets a query about a machine sold nine years ago and does not know which manual it carried.** - Links manual and certificates to the serial number on each delivery - Hands over with a signed receipt → Aftersales queries are answered in minutes, even for resold machines. **The machine is delivered and the documentation follows later.** - Delivers the file with the machine → The customer receives what covers it. **The customer asks for the manual years later.** - Keeps the file by serial number → It is provided without reconstructing. **Each machine carries a different configuration.** - Stores which configuration went out on each → You answer per unit. **A component is replaced and the documentation stays the same.** - Updates the file with every change → The paper describes what was delivered. **A customer complains and nobody knows which version they had.** - Checks that unit's file → The complaint is resolved with data. --- --- id: KB-IU-005 url: https://app.codecontract.io/help/manufacturing/plant-shutdowns-and-industrial-maintenance idioma: en categoria: sector-industria subcategoria: maquinaria audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-001, KB-CS-006] citadoPor: [KB-CF-014, KB-IU-013, KB-IU-015, KB-IU-016] --- # Plant shutdowns and industrial maintenance _Two hundred people from twenty different companies, all arriving the same morning._ **Responde a:** contractor documents for a plant shutdown · industrial subcontractor access control · coordinating contractors during a turnaround · managing work permits on site A turnaround compresses half a year of paperwork into two weeks. Companies you have never met, personnel changing daily, work permits valid for a single shift, and a plant losing money for every hour it does not run. ## Why it always jams at the gate | What fails | When it is found | Cost | | --- | --- | --- | | A worker without proof of training | At the gate, day one | Their whole crew idle | | A company without current insurance | Once they are already working | Everything done so far, in doubt | | Equipment without certification | When it is about to be used | That work front stops | | An expired work permit | During the internal inspection | A penalty and sometimes a stoppage | > [!IMPORTANT] > All four surface late for the same reason: documents are requested per company, while the problem appears per person and per piece of equipment. A contractor can be perfectly in order and bring a welder who is not. ## How to prepare in advance 1. **Open the turnaround as a file, weeks ahead** — With the list of companies and what each is asked for. 2. **Request company, people and equipment at once** — Three separate lists, not one. That is what prevents the gate jam. 3. **Let it chase by itself** — Automatic reminders until complete, with time to react. 4. **And close access to anything not current** — If the gate does not depend on document status, everything above is decorative. > [!WARNING] > The most painful case is the last-minute replacement worker. The company is approved, but the person who turns up on Monday is not on the list. Without a fast lane to register someone new with their documents, that crew is left outside or walks in unchecked — and both options are bad. ## During the turnaround **En corto** - Who is on site right now, by company. - What expires in the next 48 hours. - And which work permits are open, and whose. Those three questions, answerable from a phone, are the difference between coordinating a turnaround and chasing it. And they are the same ones an inspector will ask. > [!NOTE] > When it ends, the turnaround file closes with everything inside: who entered, with what documentation, on what dates. The next one is prepared by copying that structure, not starting over. **What if the contractor brings their own system?** They can still supply their documents; what you require does not change. **Does it work for day-to-day maintenance?** Yes, and it is easier: fewer companies and less turnover. **Can the review be delegated to the main contractor?** It can be shared, but coordination responsibility stays with you. ## Ejemplos **A plant prepares a turnaround with eighteen contractors and three hundred people.** - Opens the file five weeks ahead and requests company, people and equipment separately - Ties gate access to document status → Every crew gets in on day one and the gate stops being the bottleneck. **The shutdown lasts three days and documentation is prepared on the first.** - Closes the documentation days beforehand → The shutdown is not lost over a paper. **Eight firms come in at once.** - Checks everyone's status on one screen → The whole is visible without opening eight folders. **A machine arrives without its documentation.** - Also checks equipment before entry → What goes in has been checked. **Work is executed and no record of it remains.** - Captures the evidence at the workface → Start-up is decided with the work in view. **After the shutdown, questions arrive about an intervention.** - Keeps the shutdown's file → You answer from the record. --- --- id: KB-IU-006 url: https://app.codecontract.io/help/manufacturing/sectors-with-part-level-traceability idioma: en categoria: sector-industria subcategoria: aeronautica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-001, KB-CS-010, KB-IU-030] citadoPor: [KB-IU-007, KB-IU-031] --- # Sectors with part-level traceability _Aerospace, rail, marine: every part carries its history for decades._ **Responde a:** aerospace part traceability · material certificates by heat number · documentation accompanying a critical part · rail component traceability Some sectors have documentation that does not accompany the order: it accompanies the part, and does so for its whole service life, which can be thirty years. Aerospace, rail, marine, nuclear and pressure equipment share that demand, and with it a failure mode of their own. ## What travels with each part | Document | What it evidences | How long it is needed | | --- | --- | --- | | Material certificate | Which heat the metal came from | The component's whole life | | Process certificates | Heat treatment, welding, coating | The same | | Non-destructive testing | That it was checked and with what result | The same | | Operator qualification | That the welder was certified that day | And that it was valid on that date | > [!IMPORTANT] > The last row is most underestimated. It is not enough for the welder to hold the qualification: you must be able to show it was **valid on the specific day** the joint was made. A certificate that lapsed two weeks earlier invalidates the work done after. ## The typical failure mode It is not losing a document: it is being unable to show which part it belongs to. When certificates are filed by supplier or by date instead of by heat and part number, they all exist and none is useful, because nobody can rebuild the association. 1. **The part identifier rules** — Everything hangs off it: heat, processes, tests, who and when. 2. **Documentation arrives with the material** — Not afterwards. A certificate arriving three weeks later no longer finds its part. 3. **Qualifications, with validity and warnings** — It is what prevents work done by someone whose certification has lapsed. 4. **And the set is kept for decades** — Outside the production system, which will change several times in that period. > [!WARNING] > The fourth point causes long-term trouble. If documentation lives inside a proprietary system replaced every eight years, each migration is a chance to lose the part-document link. You should be able to export the set in a self-readable form. ## Customer audits **En corto** - They pick a part at random and ask for its full history. - They check that signatures and qualifications were valid on their date. - And they look at whether you can show it without depending on one person. > [!NOTE] > The same pattern applies to pressure equipment, lifting gear and automotive safety components. The reference standard changes; that the filing unit is the part rather than the order does not. **What about parts made twenty years ago?** Keep whatever exists; from today, structure by part. **Is paper acceptable?** It is, but it cannot answer in minutes or check validity by itself. **Can it be sealed so the date is not disputed?** Yes, and for documentation kept for decades it adds a lot. ## Ejemplos **A machining shop files material certificates by supplier and month.** - Reorganises by heat and part number - Links operator qualifications with their validity → Answers a customer audit on a specific part in minutes, with validity provable. **The part is identified and the link is lost at assembly.** - Ties the part to the assembly as it goes in → The backward journey survives assembly. **A client asks about one specific part.** - Checks that part's file → You reach the heat or the origin batch. **The material certificate arrives after production.** - Attaches it to the consignment on receipt → The certificate lives with what it covers. **A consignment problem must be contained.** - Checks which parts came out of it → Scope narrows to what is affected. **A review asks about parts from years ago.** - Keeps the files with their dates → You answer from the archive. --- --- id: KB-IU-007 url: https://app.codecontract.io/help/manufacturing/metalwork-and-contract-machining idioma: en categoria: sector-industria subcategoria: metalurgia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-006, KB-IC-012] citadoPor: [KB-CN-010, KB-IU-017] --- # Metalwork and contract machining _Many small orders, drawings that change, and customers asking for certificates months later._ **Responde a:** drawing revision control in a workshop · material certificates for customers · machining traceability · orders with different drawing revisions A machining or fabrication shop lives on many small orders. The documentary problem is not volume: it is that each order carries a drawing at a specific revision, a material with its certificate and sometimes an outsourced treatment, and all of it disappears as soon as the part ships. ## The three failures that cost money | Failure | How it happens | Consequence | | --- | --- | --- | | Making to the previous revision | The customer emails a new revision | The whole run to be redone | | Being unable to provide the certificate | It is asked for six months later | Payment withheld or the customer lost | | Losing the outsourced treatment record | A third party does it and their paper stays there | The assembly ends up unevidenced | > [!IMPORTANT] > The first is the costliest and the most avoidable. If the current drawing lives in the order's file rather than in the inbox of whoever received it, nobody can make to a superseded revision without it being visible. ## How to organise it 1. **The order is the file** — Drawing with its revision, material, treatments and inspections, all inside. 2. **Each new revision visibly supersedes the last** — The old one is not deleted: it is marked. It tells you what was made and to what. 3. **The certificate arrives with the material** — That day. Hunting for it six months later is why it never turns up. 4. **And outsourced treatment returns with its document** — If only the part comes back, the set is incomplete and nobody notices until it is requested. > [!WARNING] > The blind spot is the sales inbox. Drawings and revisions usually land there, and if that person is on holiday the shop works from whatever was last passed on. It is the origin of failure number one. ## What demanding customers ask for **En corto** - The material certificate for that part, not for the supplier in general. - The drawing and revision it was made to. - The inspections carried out and their results. - And sometimes the welder's qualification, with its validity. When that is answered in minutes, you become the easy supplier. When it takes a week, you are the supplier who has to be chased — and that weighs in the next award. > [!NOTE] > The same approach suits fabrication, structural steel, laser cutting and processing generally: the unit is the order, and traceability runs from material to delivered part. **What if the customer never asks for certificates?** Keep them anyway: they ask exactly when there is a problem. **Is it needed for one-off parts?** The drawing always. The rest, depending on customer and material. **How do we avoid making to an old revision?** Have the shop look at the file, not a forwarded email or an undated printout. ## Ejemplos **A shop makes a run to the previous revision of a drawing received by email.** - Moves to keeping the current drawing in the order's file - Marks earlier revisions instead of deleting them → The shop looks in one place only and can prove which revision each run was made to. **The drawing comes from the client and there are several versions.** - Records which version each batch was made to → You know what was made to which drawing. **The client supplies the material and it is not recorded.** - Records intakes and consumption per client → You answer when they ask. **A client asks for a part's material certificate.** - Ties the part to the consignment received → The certificate is located without searching. **The drawing changes midway through a run.** - Records from which unit it applies → You can say what each one carried. **Material is left over and there is a dispute over whose it is.** - Agrees in writing what happens to leftovers → The conversation is settled by the agreement. --- --- id: KB-IU-008 url: https://app.codecontract.io/help/manufacturing/change-control-in-production idioma: en categoria: sector-industria subcategoria: farmaceutica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-002, KB-IC-009] citadoPor: [KB-IU-009, KB-IU-023, KB-IU-030] --- # Change control in production _Changing a supplier, a parameter or a machine, without it becoming an audit finding._ **Responde a:** documented change control · changing a validated supplier · modifying a production process paperwork · change management in manufacturing In any regulated manufacturing, change is not the problem: the problem is the change that happened with no record that anyone assessed it. An auditor will not fault you for changing an excipient supplier; they will ask who assessed the impact and against what criteria. ## The changes that slip through | Change | Why it slips | What should have remained | | --- | --- | --- | | A raw material supplier | Purchasing decides on lead time or price | Impact assessment and approval | | A parameter adjustment | Done on the floor and it works better | Justification and who authorised it | | A repair with a different part | The original was not arriving in time | Equivalence and later verification | | A software or version change | Done by maintenance or IT | Impact on records and validations | > [!IMPORTANT] > The fourth row grows fastest and is least treated as a process change. An equipment or software update can alter how data is recorded, and that affects validation even though the machine still does the same thing. ## What a change record must contain 1. **What is changing and why** — In one line understandable by someone who was not there. 2. **What impact it may have and on what** — Product, process, records, validations, other areas. 3. **Who approves it** — With a name and a date; an approval without an author is not an approval. 4. **And how it is verified afterwards** — Later verification is what closes the change; without it, it stays open. > [!WARNING] > The usual error is not doing the record badly: it is doing it afterwards. Change control signed three weeks later, with production already run, assesses nothing — it documents a decision already taken, and it shows. ## How to sustain it without slowing the plant **En corto** - A fast lane for minor changes, decided in advance. - A clear threshold for what is minor and what is not. - And assessment before applying, however brief. Without a fast lane, people bypass the process to get work done, and then you do not have a strict system: you have a system that is not followed. A light procedure that is followed beats a perfect one that is dodged. > [!NOTE] > The same approach suits medical devices, cosmetics, certified food schemes and automotive: the reference standard and threshold change, not the logic of assessing before and verifying after. **What about emergency changes?** Do them and document immediately after, with that condition stated. **Is it needed for a packaging supplier change?** If it touches the product or its preservation, yes. It is among the most underestimated. **Who should approve?** Whoever answers for product quality, not whoever makes the change. ## Ejemplos **A plant changes a component supplier because of lead times.** - Records the change with impact and approval before using it - Verifies the first batch made with the new one → The audit finds the change assessed and closed, instead of a finding. **Something changes and is documented weeks later.** - Records the change before applying it → The file describes what is done. **Nobody knows from which batch a change applies.** - Records from which unit it takes effect → You can say what each batch carried. **A change affects documentation nobody reviews.** - Reviews which documents describe what changes → The papers keep describing the product. **The client asks to be told of any change.** - Records what was communicated and when → The commitment is demonstrable. **A review asks about an old change.** - Keeps the change history with its dates → You answer from the record. --- --- id: KB-IU-009 url: https://app.codecontract.io/help/manufacturing/electronics-and-component-substitution idioma: en categoria: sector-industria subcategoria: electronica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-008, KB-NO-007] citadoPor: [KB-IU-012, KB-NO-025, KB-IU-020] --- # Electronics and component substitution _A component goes end-of-life and must be swapped. Documentation does not travel with the function: it travels with the part number._ **Responde a:** replacing an obsolete component · material declarations for electronic components · part number change in a bill of materials · documented component equivalence In electronics, obsolescence is not an exception: it is the calendar. A component is discontinued, an equivalent has to be found, and the product stays the same for the customer. On paper, however, it has changed — and that is where problems pile up. ## What moves when a part number changes | Document | Still valid? | Why | | --- | --- | --- | | Manufacturer material declarations | No | They were issued for the previous part number | | Component conformity certificates | No | The same: they follow the part number, not the function | | The product's bill of materials | Must be updated | And the previous version kept, for what was already built | | Technical documentation of the finished product | It depends on the change | If it affects safety or what was declared, it is reviewed | > [!IMPORTANT] > The key is the first row and it is what gets underestimated most: frameworks such as RoHS or REACH are answered with declarations the manufacturer issues **for a specific part number**. An "equivalent" component from another maker does not inherit those declarations even if it does exactly the same job. If you do not request the new ones, your finished product has quietly lost its documentary backing. ## How to make a substitution that survives an audit 1. **Document the equivalence, not just the decision** — What was compared and against what criteria, not "it's the same". 2. **Request the new component's documentation before fitting it** — Material declarations and certificates, for that part number. 3. **Record from which serial or batch it applies** — It is what lets you answer years later what each unit contained. 4. **And keep the previous bill of materials** — What was built before is supported by that one, not the new one. > [!WARNING] > Point three separates an orderly substitution from a silent problem. Without the marker "from here the new part is fitted", two years on you will have units in the field with two configurations and a single bill of materials describing only one. When a claim arrives about a specific unit, you will not know which it carried. ## The awkward case: buying outside the usual channel **En corto** - If a component is scarce, offers from unfamiliar distributors will appear. - There documentation matters more, not less: batch traceability and the original manufacturer's declarations. - And record where each purchase came from, not only what it cost. Counterfeit components exist, and their first symptom is not an electrical failure: it is incomplete or generic documentation that does not refer to a specific batch. > [!NOTE] > The specific substance frameworks and their scope vary by product and market, and they get updated. This describes how to organise the documentary response; **what applies to you and from when is worth confirming with your adviser** or the manufacturer, not inferring from a distributor's listing. **Is the distributor's declaration enough?** As a reference yes; what holds up is the manufacturer's, for that part number. **Do product tests have to be redone?** It depends whether the change affects what was tested; that assessment is documented too. **What if only the package changed?** It is still another part number, so it still needs its own documentation. ## Ejemplos **A manufacturer replaces a discontinued component with an equivalent and carries on producing.** - Requests the new component's declarations before fitting it - Marks the serial number it applies from and keeps the old bill of materials → Facing a claim on a two-year-old unit, it can say exactly what that unit contained. **A component is discontinued and must be substituted.** - Checks that version's design file → The substitution starts from what was decided. **It is substituted and the documentation still describes the old one.** - Updates the file with the new component → The paper describes what is made. **Units with the old and new component coexist.** - Records from which batch the change applies → Each unit has its documentation. **The new component's supplier provides no documentation.** - Requests it before starting to use it → The change leaves no gap. **A client asks what one specific unit carried.** - Checks that batch's file → You answer per unit. --- --- id: KB-IU-010 url: https://app.codecontract.io/help/manufacturing/timber-and-wood-products-origin-and-treatment idioma: en categoria: sector-industria subcategoria: madera audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-010, KB-IU-003] citadoPor: [KB-IU-013] --- # Timber and wood products: origin and treatment _Three separate sets of documentation people conflate: where it came from, how it was treated, and what it emits._ **Responde a:** documentation for the timber we buy · fsc pefc chain of custody · pallet treatment for export · board certificates and emissions Timber carries three sets of documentation answering different questions, and conflating them is what makes a company believe it is covered when it is not. None replaces the other two. ## The three, and what each answers | Documentation | Answers | Who issues it | | --- | --- | --- | | Origin and legality | Where this timber came from | Your supplier, with their chain backwards | | Chain of custody | That certified material was not mixed with uncertified | The certification scheme, in your name | | Packaging treatment | That the pallet or crate was treated for travel | Whoever made or treated it, with their mark | | Board performance | Emissions, reaction to fire, intended use | The board manufacturer | > [!IMPORTANT] > The second row is the most misread. A chain of custody certification **does not say the timber came from a specific forest: it says you handle it without mixing it with uncertified material**. That is why it is yours, not your supplier's, and why buying from a certified supplier does not certify you. ## The case that catches most companies > [!WARNING] > Wooden export packaging carries its own treatment and mark, and **depends not on what you do with the product but on where it goes**. A company that has never touched timber can have a container held at destination because the pallets lacked the right mark. It is the classic first-shipment failure to certain countries, and it is avoided by asking the forwarder before loading, not after. ## What to hold per supplier **En corto** - Their origin documentation, referenced to the supply rather than generic. - Their certificate, with scope and date, if you buy certified material. - The product datasheet if it is board or a processed product. - And renewal warnings: these certificates expire and get checked exactly when a large order lands. ## If you process and sell 1. **Your declaration is yours** — What you say about the finished product is answered by you, not your supplier. 2. **Keep traceability backwards** — Which material consignment went into which outgoing order. 3. **And physically separate certified stock** — If it gets mixed in the warehouse, the chain of custody breaks even with the paperwork still in the file. > [!NOTE] > Certification schemes, due diligence obligations on origin and packaging requirements vary by product and destination country, and they get updated. **Confirm what applies and with what scope with your adviser, the scheme or your forwarder**; this describes what documentation exists and which question each answers. **Does my supplier's certificate count as mine?** No. Theirs evidences their chain; yours begins when the material enters your warehouse. **What if I buy already-processed timber?** It still has an origin and obligations still attach to it: ask for it anyway. **Do reused pallets count too?** If they travel abroad, yes: what matters is the pallet's mark, not how often it has been used. ## Ejemplos **A company buys from a certified supplier and advertises itself as certified.** - Checks that chain of custody is its own and not inherited - Physically separates certified stock in the warehouse → Stops claiming something it could not support and prepares certification properly. **The origin is asserted by the supplier with no document.** - Requests the document that backs it → The claim stops being only a claim. **Consignments of different origins get mixed.** - Records what went into each production run → You can say what came from where. **A client asks for the origin of one specific supply.** - Checks that delivery's file → You answer per delivery. **The treatment certificate arrives later.** - Attaches it to the consignment on receipt → The certificate lives with what it covers. **The supplier changes origin and does not say so.** - Asks them to report any change → The change arrives before the question. --- --- id: KB-IU-011 url: https://app.codecontract.io/help/manufacturing/recovery-and-recycling-material-arriving-without-paperwork idioma: en categoria: sector-industria subcategoria: reciclaje audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-003, KB-NO-009, KB-IU-015] citadoPor: [KB-NO-019, KB-IU-014, KB-IU-027] --- # Recovery and recycling: material arriving without paperwork _The business is receiving what others discard, and there the paperwork arrives late, incomplete or not at all._ **Responde a:** intake documentation at a recycling plant · waste supplier control · recovered material traceability · accepting material without documentation A recovery plant has a different origin problem from any other industry: its suppliers are not manufacturers wanting to sell, they are companies wanting to get rid of something. The incentive to document it properly is inverted, and that shows at the weighbridge. ## The three moments to capture | Moment | What to record | What happens otherwise | | --- | --- | --- | | Intake | Who brings it, what it is and where it came from | Material enters with no origin and it cannot be reconstructed | | Sorting | What is accepted, what is rejected and why | An unrecorded rejection turns into an argument | | Dispatch | What leaves, to whom and with what paperwork | The chain breaks exactly where it is most scrutinised | > [!IMPORTANT] > The intake record supports everything else, and it is the only one that must happen with the lorry in front of you. If origin is noted "later, from the delivery note", what happens in practice is that the haulier gets recorded and not the producer — and the producer is exactly what you will be asked about. ## The awkward case: material that should not have arrived > [!WARNING] > Sooner or later a load arrives with something that does not match: a different waste from the one declared, contaminated material, or something you simply cannot accept. **Rejecting it without recording the rejection leaves you in the worst of both positions**: you do not have the material, and you do not have proof that you returned it or what it was. Rejection is documented exactly like acceptance, with a photo and who brought it. ## What to hold per supplier **En corto** - Their authorisation or status to deliver that material to you. - Which material types you have agreed to receive from them. - Their incident history, which in this sector is the best predictor. - And expiry warnings on whatever authorises them, because it expires like everything else. The third pays off here more than in any other sector: a supplier who has already brought two mis-declared loads will bring a third, and that knowledge usually lives in the weighbridge operator's head and nowhere else. ## Where this is heading 1. **Customers increasingly ask for the origin of recovered material** — Especially whoever puts it into new product and has to declare it. 2. **And they ask for percentages with backing** — A recycled-content figure with no traceability behind it is a hard claim to sustain. 3. **What positions you is being able to evidence it** — In a sector where hardly anyone can, that is the commercial difference. > [!NOTE] > The authorisations required, the transfer documents and what counts as waste or as material depend on the type, the destination and the region, and they change. **Confirm that with your adviser or the competent authority**; this describes what to record at the plant so that documentation makes sense afterwards. **What if the supplier brings no paperwork?** Record the intake anyway with what exists and chase them; what cannot happen is entry with no record. **Must every load be photographed?** Rejected and doubtful ones, always. The rest, by your own risk criteria. **Is the weighbridge ticket enough as a record?** As weight yes; as origin no, unless it links to who produced it. ## Ejemplos **A plant rejects a mis-declared load and sends it back with nothing recorded.** - Starts photographing and recording rejections too, with who brought them → When that supplier repeats it, the decision to stop working with them is documented. **Material arrives with no documentation at all.** - Records origin, supplier and date on receipt → The material has a known provenance. **The supplier is occasional and does not return.** - Records their details at the intake itself → Traceability does not depend on a stable relationship. **Material from several intakes gets mixed.** - Records which intakes make up each batch → The backward journey exists. **A client asks for the origin of the recycled material.** - Checks that consignment's file → You answer per consignment. **A review asks about intakes from a year ago.** - Keeps the record with its date → You answer from the archive. --- --- id: KB-IU-012 url: https://app.codecontract.io/help/manufacturing/plastics-converters-and-recycled-content idioma: en categoria: sector-industria subcategoria: plasticos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-IU-009] citadoPor: [KB-IU-020] --- # Plastics converters and recycled content _Claiming a recycled percentage is easy; supporting it with documentation is not._ **Responde a:** recycled content documentation · food contact declaration for plastics · changing resin supplier · evidencing recycled content A converter lives between two demands pulling in different directions: customers want more recycled material, and at the same time want the product to keep meeting the same requirements. On paper, those two things rest on different documents and neither covers the other. ## The three declarations that are not interchangeable | Declaration | What it asserts | What supports it | | --- | --- | --- | | Composition and performance | What the material is and how it behaves | Your resin supplier, per reference | | Suitability for use | That it fits the intended application | Your supplier and, depending on use, you | | Recycled content | What proportion comes from recovered material | Your intake traceability, not a promise | > [!IMPORTANT] > The third is the most asserted and the worst supported. A recycled percentage **is not a product characteristic: it is the result of a balance between what came in and what went out**. If you cannot reconstruct which material went into which production run, the figure you give is an estimate — and the moment a customer audits it, that distinction shows. ## What you must be able to show 1. **What material came in, from whom and with what documentation** — Including recovered material, which arrives with the poorest paperwork. 2. **What was produced from what** — The link between intakes and outgoing batches, as in any traceability. 3. **The criterion used to calculate the percentage** — Written once and applied identically: varying it between customers gets detected. 4. **And what happens when the supplier changes** — Another resin is another reference, and it drags new declarations with it. > [!WARNING] > The point that surprises on a supplier change: even with equivalent material, **declarations follow the reference and are not inherited**. Switching resin on price or availability is a purchasing decision that drags technical documentation, and if nobody tells whoever maintains the declarations, your finished product quietly loses its backing with nothing visible changing. ## When the end use is sensitive **En corto** - Food contact, medical or children's uses add their own requirements to material and process. - And recovered material in those uses has specific conditions that do not apply to any origin. - That is not settled by the resin supplier's declaration: check it before accepting the order. > [!NOTE] > Which frameworks apply to each use, what may be declared and with what backing depends on the product, the destination and the market, and it gets updated. **Before committing to a percentage or a use in an order, confirm with your adviser or the resin manufacturer**; this only explains what documentation exists and what each asserts. **Does the supplier's declaration support the percentage?** It supports what they supplied, not the balance of your production. **What if we blend batches of different origin?** Then the calculation criterion is what must be written down and applied consistently. **How long must it be kept?** Whatever the end use requires, with margin: in packaging, longer than the life of the product it holds. ## Ejemplos **A converter offers a recycled percentage and a customer asks to audit it.** - Reconstructs the balance from intakes and outgoing batches - Writes down the calculation criterion and applies it uniformly → It can sustain the figure in the audit instead of admitting it was an estimate. **The recycled content is declared with no backing.** - Stores what backs it with the reference → The declaration holds up. **The supplier changes the blend and nobody knows.** - Asks them to communicate any change → The change arrives before the question. **A client asks you to evidence one specific run.** - Checks that production run's file → You answer per run. **Intakes from different suppliers get mixed.** - Records what went into each run → You can say what came from where. **The supplier's documentation expires.** - Records expiries per supplier → The warning arrives before producing. --- --- id: KB-IU-013 url: https://app.codecontract.io/help/manufacturing/energy-use-what-you-will-be-asked-for idioma: en categoria: sector-industria subcategoria: energia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-016, KB-IU-005, KB-IU-010] citadoPor: [KB-CN-035, KB-IU-026] --- # Energy use: what you will be asked for _The request rarely comes from a regulator: it comes from a client, in a format to be filled with data that is not yours._ **Responde a:** asked for energy consumption data · where do I get the plant's electricity use · guarantees of origin for energy · energy audit documentation For years energy was an invoice and little more. Now it shows up in large clients' questionnaires, in tenders and in the reports your own buyers request — nearly always with the same surprise: the data needed is not yours to give. ## Who holds each piece of data | What you are asked for | Who holds it | How it reaches you | | --- | --- | --- | | Consumption per period | Your energy supplier | Invoices or their portal, in their format | | Origin of the electricity | The supplier | A certificate you must request; it does not just arrive | | Gas or fuel consumption | The supplier | Delivery notes and invoices, sometimes per supply point | | An item of equipment's efficiency | Whoever installed or maintains it | In its technical documentation | | What you do to reduce it | You | And it is the only part nobody else can provide | > [!IMPORTANT] > The second row throws many people: **your electricity being renewable is not proven by the invoice or by your supplier's marketing**. It is proven by a specific certificate, covering a specific period, which has to be requested and is not always issued on the spot. Whoever asks in October for a September report usually finds it arrives late, and there is no reconstructing it afterwards. ## How to set it up once and not repeat it 1. **One file per supply point** — With its invoices, its contract and its certificates. 2. **Download invoices monthly, not per report** — Supplier portals have short memories. 3. **Request the origin certificate as soon as the period ends** — It is the slowest piece and the most forgotten. 4. **And keep what you did to cut consumption** — Equipment changes, schedules, maintenance: that is what sets you apart. > [!WARNING] > What almost nobody anticipates when switching supplier: **the history stays in the previous one's portal**, and access is cut when the contract ends. If you are asked for three years of consumption and you switched a year ago, that stretch only exists if you downloaded it. Pulling the full history before closing the relationship takes twenty minutes and is unrecoverable afterwards. ## When the one asking is a client **En corto** - It usually comes in their format, not yours: fill it from what you already keep. - It asks about specific periods, so the data has to exist month by month. - And it will come back next year: setting it up once serves every time after. > [!NOTE] > What obligations you have on efficiency or energy audits, and how often, depends on your size, sector and country. **Your adviser determines that**; the point here is that when the question arrives — from whoever — the data is already gathered rather than chased. **Is sending the invoices enough?** Rarely: they ask for aggregate figures per period, and someone has to add them up. **What if we have several plants?** Per supply point, always. Mixing them means undoing it later. **Is last year's figure useful?** For comparison yes, which is why the history is worth keeping. ## Ejemplos **A plant switches energy supplier and months later a client asks for three years of consumption.** - Downloads the full history before closing the previous contract → The report is filled from its own data, without depending on the portal of a former supplier. **The figure sits in invoices spread across the year.** - Gathers them as they arrive → The calculation is prepared without a campaign. **A supplier's figure is missing.** - Requests it and chases automatically → The deadline does not depend on somebody else's diary. **A figure is declared and no evidence is kept.** - Stores the evidence with what was declared → The later review has something to answer with. **Nobody knows how last year's was calculated.** - Records the basis alongside the calculation → The figure is explicable years later. **A client asks for the figure for a specific period.** - Checks that date's record → You answer from the archive. --- --- id: KB-IU-014 url: https://app.codecontract.io/help/manufacturing/quarries-and-aggregates-what-travels-with-each-load idioma: en categoria: sector-industria subcategoria: mineria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-010, KB-IU-011] citadoPor: [KB-CN-020, KB-IU-023] --- # Quarries and aggregates: what travels with each load _Sold in bulk, by the lorry and in a hurry, and yet every load has to be explainable months later._ **Responde a:** aggregate supply documentation · declaration of performance for aggregates · quarry production control · asked for tests on the material supplied The business is measured in tonnes and loading times: the lorry comes in, gets loaded, leaves with its docket. But the site that material goes to has to justify years later what was laid there, and that justification starts at your weighbridge. ## What travels with each supply | Piece | What it proves | Where it is produced | | --- | --- | --- | | Docket with product and quantity | What left and where for | At the weighbridge | | Identification of the product supplied | Exactly which material it is | From the catalogue, not the quarry's nickname | | Performance documentation for the product | That it matches what is declared | From production control | | The period's tests | That the declaration is backed by data | From the lab, in-house or external | > [!IMPORTANT] > What breaks traceability is not in the paperwork, it is in the yard: **material is identified by the stockpile it is loaded from, and stockpiles get mixed**. If a pile is topped up with new production before the previous one is closed, that lorry carries material from two periods and its tests no longer describe it. Nobody notices until there is a problem on site and that day's test is requested — and by then the right answer no longer exists. Recording which stockpile was loaded is what ties the load to the tests. ## What is worth setting up 1. **A product catalogue with unique names** — The quarry's internal nickname does not belong on a docket. 2. **The stockpile identified and noted on the load** — It is the link between the lorry and the tests. 3. **Tests filed by product and period** — Not loose in the plant manager's inbox. 4. **And performance documentation available to the client** — Their site engineer will ask, not them. > [!WARNING] > What surprises suppliers: **the request does not come from your client, it comes months later and from the site**. Whoever asks is usually the site engineer or a testing lab, holding a docket and a specific date. If the docket only says «hardcore» and identifies neither product nor stockpile, answering means reconstructing from the memory of whoever was loading that day — and months on, that reconstructs nothing. ## If you also produce recycled material **En corto** - The origin of what comes in weighs as much as the test on what goes out. - And you must be able to separate what came in from where, not only what left. - There, inbound traceability is what holds everything else up. > [!NOTE] > Which documentation must accompany each type of aggregate, what production control is required and which tests at what frequency depend on the product, its intended use and the applicable rules. **Your adviser or your laboratory settles that**; here it is about every lorry being tied to what belongs with it. **Must the stockpile be on the docket?** Even where nobody requires it, it is what lets you answer later. **What if the client loads with their own lorry?** Same: what matters is what was loaded and from where. **How long to keep the tests?** Longer than the site the material went to, which tends to be a while. ## Ejemplos **A quarry gets a site query about a delivery from eight months ago.** - Records the stockpile loaded on each docket and files tests by product and period → The answer comes from that day's record, not from whoever happened to be loading. **The delivery note leaves with the lorry and no copy remains.** - Captures the note at loading → The record does not travel in the cab. **A client asks for one specific supply's test results.** - Attaches tests to the consignment delivered → You answer per delivery. **Nobody knows what was supplied to which site.** - Records destination and date on every load → The question has an answer. **Test results arrive from the lab and are filed loose.** - Attaches them to the corresponding production → The test lives with what it analyses. **At a project's close-out, months of supplies are requested.** - Keeps each delivery with its date and destination → The handover is prepared in an afternoon. --- --- id: KB-IU-015 url: https://app.codecontract.io/help/manufacturing/shipyards-and-ship-repair idioma: en categoria: sector-industria subcategoria: naval audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-023, KB-IU-005] citadoPor: [KB-IU-011] --- # Shipyards and ship repair _A vessel comes in with a work list and leaves with a record that follows it for life, to other ports and other yards._ **Responde a:** ship repair documentation · work on board and subcontractors · what to hand the owner at the end · certificates for a vessel repair A yard stay compresses into a few weeks what a factory would spread over months: dozens of simultaneous jobs, several companies aboard at once, and a client whose vessel cannot stay a day longer. Documentation is produced alongside the work or it is not produced at all. ## What piles up during the stay | Front | What documentation it leaves | Who needs it later | | --- | --- | --- | | The work carried out | Reports, measurements and tests | The owner and the next yard | | Materials installed | Material certificates and traceability | Whoever inspects that equipment | | Companies that came aboard | Their documents and their people's | You, if anything happens | | Incidents and scope changes | What was approved and by whom | The final invoice, where it gets argued | > [!IMPORTANT] > The fourth row moves the most money and is documented worst: **during a stay the scope changes daily, and what is approved verbally on deck gets invoiced weeks later**. If an extra job was authorised in a conversation with the chief engineer and nobody wrote it down, the final discussion is not technical, it is about memory — and the payer's memory and the worker's rarely match. One line written the same day, with who authorised it, beats any later report. ## What to have before they come aboard 1. **Each company's documentation, current** — The same logic as site access control, with less slack. 2. **Who their supervisor is and who they answer to aboard** — With several firms working at once, there is no coordination without it. 3. **And each one's scope, in writing** — It prevents work done twice and work done by nobody. > [!WARNING] > What sets this sector apart from almost any other: **the record travels with the vessel, it does not stay at the yard**. What you hand over at the end is what the owner will show at the next port, at an inspection or at the next repair, possibly in another country and another language. An incomplete record does not inconvenience you — it inconveniences the client months later, and that is why owners change yards. ## What is worth handing over at the end **En corto** - The work carried out, with its measurements and tests. - Certificates for what was installed, not just the invoice. - What was left pending or recommended for the next stay. - And in the language whoever reads it later will need. > [!NOTE] > Which certifications each job requires, which inspections must be witnessed and what the classification society or flag demands depends on the case. **The owner, their surveyor or your adviser settles that**; here it is about what is generated during the stay not scattering across four workshops. **Should we keep a copy of what we hand the owner?** Yes: it is your evidence of what was done and how it was delivered. **What about a subcontractor's work?** Their documentation goes into the record too: the owner asks you, not them. **How long to keep it?** Longer than the warranty; vessels come back years later. ## Ejemplos **A yard invoices extra work approved verbally during the stay and the owner disputes it.** - Records each scope change the same day, with who authorised it → The final invoice is argued from what was written, not from what each side remembers. **The repair is documented at the end and half is missing.** - Captures evidence as it is executed → The file completes itself. **Several firms come aboard the same vessel.** - Checks everyone's status before authorising → The whole is visible at once. **The owner asks you to evidence an intervention.** - Checks that repair's file → You answer from the record. **A part is replaced and there is no record of which.** - Records what was replaced and why → The vessel's history is true. **A review asks about work from years ago.** - Keeps the file with its date → You answer from the archive. --- --- id: KB-IU-016 url: https://app.codecontract.io/help/manufacturing/the-inspections-that-fall-due-by-calendar idioma: en categoria: sector-industria subcategoria: maquinaria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-005, KB-CF-014] citadoPor: [KB-IU-019] --- # The inspections that fall due by calendar _Nobody skips an inspection on purpose. They get missed because the reminder lived in the head of whoever retired._ **Responde a:** mandatory periodic equipment inspections · statutory inspection overdue · tracking legal maintenance of installations · who keeps track of machinery inspections Every industrial site has an invisible list: the compressor, the overhead crane, the electrical installation, the extinguishers, the forklift, the boiler. Each with its own frequency and its own company that comes to look at it. Nobody forgets them out of negligence; they get forgotten because the list is not written anywhere and lives split between three people's memory and a wall calendar. ## The four ways to end up late | How it happens | How it looks from inside | | --- | --- | | The inspecting company stopped calling | «They used to remind us» | | The inspection happened but no report arrived | «It's done, they'll have the paper» | | The responsible person changed | «That was handled by the one who left» | | A new machine was bought | It never entered any list, because the list was mental | > [!IMPORTANT] > The second row is the most dangerous, and the one almost nobody counts as a problem: **an inspection whose report is not in your files is, for the purposes of proving it, an inspection that never happened**. It does not matter that the machine is perfect and the technician came on a Thursday. When someone asks —an inspector, an insurer after a claim, a client auditing— what gets shown is the paper. Chasing the report is part of the inspection, not a later formality. ## The list, which is the whole job 1. **One line per equipment or installation, not per supplier** — Suppliers change; the equipment stays. 2. **With its frequency and the date of the last one** — The next one follows by itself, with nobody calculating it. 3. **The report filed with the equipment's record** — Not in the inbox of whoever received it. 4. **And an alert with enough lead time to book** — Warning on the expiry date is useless: you have to call, find a slot and wait. > [!WARNING] > Buying or hiring equipment is where this collapses, and both cases are avoidable. **On buying**: the machine arrives, goes into production, and nobody adds it to any list — months later nobody knows whether anything is due. **On hiring**: it is assumed inspections are the owner's, which is usually true and still does not free you from holding the paper; if the hired machine fails at your premises, what you will be asked for is the documentation, not the hire contract. ## What you gain by having it in place **En corto** - You stop discovering what has lapsed on inspection day, when there is no margin left. - You can book with time, which nearly always means booking cheaper. - An incident does not become two problems: the incident, and being unable to evidence the maintenance. - And a change of responsible person stops being a six-month hole. > [!NOTE] > Which equipment and installations are subject to mandatory inspections, how often, who may carry them out and what must be kept depends on the equipment type and the applicable industrial rules. **Your maintenance provider or adviser settles that**; here we cover what always fails the same way: the list and the filing. **Is it enough that the maintenance company tracks it?** It helps, but the paper will be asked of you. Hold it too. **What about hired equipment?** Ask the owner for the documentation and file it like your own while it is on your premises. **What if I find a lapsed inspection?** Book it now and record when it was spotted: the reaction counts too. ## Ejemplos **An inspector asks for the last crane inspection report and all that exists is that «it was done».** - Chases the report as part of the inspection and files it with the equipment record → What was done becomes what can also be shown. **A new machine is bought and six months later nobody knows whether anything is due on it.** - Registers the equipment on the list the day it arrives, with frequency and alert → No machine lives outside the calendar just because it arrived in a hurry. **The maintenance manager retires and the inspection calendar leaves with them.** - Moves the list out of one person's head into a shared place → A handover stops opening a months-long hole in the control. **Inspections are remembered from memory.** - Records each due date with a warning → The calendar stops depending on remembering. **They all fall in the same month.** - Warns far enough ahead to spread them → The calendar spreads out. **The inspection happens and the certificate stays on paper.** - Captures it and attaches it to the equipment → The certificate lives with the equipment. --- --- id: KB-IU-017 url: https://app.codecontract.io/help/manufacturing/the-machine-shop-working-to-order idioma: en categoria: sector-industria subcategoria: metalurgia audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-007, KB-NO-024] citadoPor: [KB-IU-018, KB-IU-028] --- # The machine shop working to order _The material is either the client's or yours to buy, and that difference decides what you answer for when the part fails._ **Responde a:** machine shop part documentation · material certificate the client asks for · machined part traceability · who is liable when a machined part fails You receive a drawing, machine it and deliver. When a part fails months later, the question arrives in two very different versions depending on who bought the material — and almost no shop has that distinction written into the quotation. ## The two situations, and what you answer for in each | Who supplies the material | What you answer for | What you must keep | | --- | --- | --- | | **The client supplies it** | The process and the dimensions | Which heat it was, even though you did not buy it | | **You buy it** | The process AND the material | The mill certificate, tied to the parts despatched | | You buy it to their specification | The same, plus having met it | The specification, versioned | > [!IMPORTANT] > **A material certificate is only useful if it can be tied to the actual parts despatched.** A file full of mill certificates nobody can relate to a delivery note is paper: when the client asks about the part that failed, you will have twenty certificates and no way to say which was theirs. What ties them together is recording on the works order which material was cut, and that happens on the shop floor, not in the office. ## What to record per works order 1. **Which heat or material lot it came from** — Even if the client brought the material. Especially then. 2. **What was machined, on which machine and by whom** — It is what lets you explain a pattern if one repeats. 3. **The dimensional checks you carried out** — With which instrument, and when it was last calibrated. 4. **And which parts went out in each delivery** — Without it you cannot bound anything forwards. > [!WARNING] > Two things always slip through and appear in no record: **rework and the spare part**. A part touched up outside the normal flow and re-entering, or the three extra units made «just in case» and left on a shelf until someone uses them six months later. Both break the link between what was delivered and what was recorded — and the second is especially treacherous, because that part enters a future order carrying someone else's traceability. > [!NOTE] > What material and process documentation must be issued and kept depends on the sector you supply and on what was agreed with the client; in sectors with part-level traceability the requirements are far heavier. **Your client and your adviser settle that before you accept the order**; here we explain the split that avoids discovering it with a broken part already on the table. **If the client brings the material, am I liable for it?** Not for the material, but yes for knowing which it was. Record it anyway. **Do I have to keep mill certificates?** If you buy, yes — and tied to the parts despatched. **What about parts I make spare?** Identify them or do not keep them: they enter another order without their history. ## Ejemplos **A part fails and there are twenty mill certificates with no way to know which was theirs.** - Records on the works order which heat each run was cut from → The matching certificate is identified in minutes. **The client brought the material and nothing was recorded because «it was not ours».** - Records the material identification even when the client supplies it → You can say which material was machined, which is what will be asked. **Three spare parts are left on a shelf and used six months later.** - Identifies spare parts with their works order, or does not keep them → No part enters an order carrying someone else's traceability. **A part is touched up outside the normal flow and re-enters unrecorded.** - Logs the rework as another operation, with its date → What was delivered and what was recorded match again. **The client asks for the dimensional report and the gauge has no calibration record.** - Records which instrument was used and when it was calibrated → The verification stands up to whoever reviews it. **A delivery must be bounded and there is no record of which parts went on each note.** - Records at despatch which parts and from which works order are included → Scope is limited to one delivery instead of the whole run. --- --- id: KB-IU-018 url: https://app.codecontract.io/help/manufacturing/the-stockist-who-doesnt-manufacture idioma: en categoria: sector-industria subcategoria: componentes audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-017, KB-NO-029] citadoPor: [KB-IU-021, KB-IU-025] --- # The stockist who doesn't manufacture _You buy, cut to size and sell. You manufacture nothing, and yet you are the link where the certificate gets lost._ **Responde a:** material distributor mill certificates · selling cut-to-size material traceability · what documentation to supply with material · metal stockist certificate A six-metre bar arrives with its certificate. It is cut into four pieces for four clients. There is one certificate and four pieces — and there, in an operation lasting two minutes, it is decided whether those four clients will be able to show what their products are made of. **Traceability in distribution** — You manufacture nothing, so your only documentary contribution is **not breaking the chain**: that what leaves can be related to what came in. It sounds minor and it is exactly what you will be asked for. ## Where it breaks, by frequency | Moment | What happens | | --- | --- | | **On cutting** | **The piece loses the bar's marking** | | On mixing stock | Two intakes of the same material end up on one rack | | On despatch | It goes out without the certificate, «we'll send it on» | | On restocking | A new intake is served believing it is the old one | > [!IMPORTANT] > **Marking the piece as it is cut is the whole job, and it is where nobody wants to stop.** A number written on the material or a tag tied to it turns an anonymous offcut into a piece that knows where it came from. Without it, the certificate you hand over will be plausible but not verifiable — and when your client is in the middle of a claim, the difference between those two words is everything there is. ## What to supply and keep **En corto** - The certificate for the material supplied, not a generic one from your supplier. - With a reference letting it be related to what was taken away. - A copy of what was given to each client, in case they ask again years later. - And a record of which intake you were serving from at any given time. > [!WARNING] > The awkward case worth settling before it arrives: **a client asks for the certificate of something you sold three years ago**. If you served from an intake that no longer exists and never recorded which, there is no way to know. Sending «a certificate for that material» that is not their bar's appears to solve the moment and creates a bigger problem: you are certifying something you cannot support. Better to say plainly what you can and cannot evidence than to hand over a paper that does not correspond. > [!NOTE] > What documentation must accompany each material, what each product standard requires and what duties a distributor assumes depends on the material, the destination sector and what was agreed. **Your adviser settles that**; here we cover the part that depends only on you: not breaking the link between what comes in and what goes out. **Do I have to mark every cut?** It is what decides whether the certificate is worth anything. For demanding material, yes. **Can I send the certificate later?** You can, but the right one. Sending another is worse than sending none. **How long do I keep certificates?** Longer than your client's product life, which is not the same as yours. ## Ejemplos **A bar is cut into four and the pieces leave unmarked.** - Marks each cut with the intake reference before it leaves the yard → All four clients can show what their part is made of. **A client asks for the certificate of material bought three years ago.** - Keeps a copy of what was supplied to each client, with its reference → The correct certificate is issued instead of a similar one. **A new intake of the same material arrives and is racked next to the old one.** - Separates intakes physically or identifies which is being served → Stock is not served from one intake in the belief it is another. **Material is delivered with no certificate and a promise to send it on.** - Delivers the certificate with the material, not afterwards → The client is not left holding product they cannot document. **The certificate sent is the supplier's generic one, not the heat supplied.** - Supplies the certificate for the specific heat despatched → What is handed over is verifiable, not merely plausible. **A client claims and there is no record of which intake that order was served from.** - Records which intake was being served in each period → The claim can be bounded to one specific intake. --- --- id: KB-IU-019 url: https://app.codecontract.io/help/manufacturing/who-assembles-the-machine-and-puts-their-name-on-it idioma: en categoria: sector-industria subcategoria: maquinaria audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-004, KB-NO-024, KB-IU-016] citadoPor: [KB-IU-020] --- # Who assembles the machine and puts their name on it _You buy components from twelve suppliers and sell a machine. Twelve sets of papers do not add up to yours._ **Responde a:** machinery manufacturer technical file · i assemble machines from third party components · declaration of conformity for an assembly · who is liable for an assembled machine Every component arrives with its documentation in order. The assembly is built, tested, delivered, and the client signs happily. Months later comes the question that throws everyone: they are not asking for the components' papers, **they are asking for the assembly's** — which never existed in any box. ## The sum that does not add up | What you hold | What they ask for | | --- | --- | | Twelve documents for twelve components | One document for the assembly | | Each compliant separately | That the assembly is, running together | | Each maker's manual | A manual for your machine | | Nothing about how they interact | **Precisely that, and only you know it** | > [!IMPORTANT] > **By assembling, you become the manufacturer of something new.** It is the step most often overlooked, and it is no formality: the risks of an assembled machine are not the sum of its parts' risks — they appear in the interaction, in combined movements, in what happens when one component fails and the rest keeps running. Nobody but you can document that, because nobody else has seen the whole assembly. ## What to build besides the machine 1. **The assembly's file, not the component folder** — With a risk assessment of the assembly in operation. 2. **Each component's documentation, inside it** — Stored, not linked to the supplier's website. 3. **A manual for your machine** — Twelve supplier manuals are not the machine's manual. 4. **And which version of each component each serial number carries** — It is what lets you answer when a supplier changes. > [!WARNING] > The point always discovered late: **the component swapped for an equivalent on one specific unit**. A supplier stops delivering, a similar one goes into the three machines built that month, and nobody records it anywhere. From then on the file describes a machine that is not the one the client has — and when that client asks for a part, an adjustment or a service, the information you give will be another machine's. > [!NOTE] > What duties an assembler assumes, when the result counts as a new machine and what documentation must be issued and kept is set by the applicable product rules. **Your adviser or notified body settles that before the first delivery**; here we explain why a component folder is not the assembly's file. **Are the components' papers enough?** They are part of the file. The assembly needs its own. **What if I only integrate without modifying?** It depends on the case, and it is exactly the question for your adviser. **How long do I keep the file?** Counted from the last unit sold, not from the design. ## Ejemplos **You are asked for the assembly's file and all that exists is a folder of component papers.** - Builds the assembly's file with a risk assessment of it in operation → The document describing the machine you sell exists, not just its parts. **A component is swapped for an equivalent on three units and nothing is recorded.** - Records which version of each component each serial number carries → The file describes the machine each client actually has. **The manual handed over is a folder containing the twelve supplier manuals.** - Writes the manual for your machine, covering what the assembly does → The client knows how to use the machine, not twelve loose components. **A component's documentation was linked to the supplier's website, which was redesigned.** - Keeps a copy of every document inside the file → The file survives other people's website changes. **A client asks for a spare part and is given one from another version.** - Checks what that serial number carried before answering → The spare fits first time and does not generate a second visit. **The last unit is sold and the file is archived as closed.** - Keeps the file counting from the last unit sold → The file still exists when the question arrives, years later. --- --- id: KB-IU-020 url: https://app.codecontract.io/help/manufacturing/the-importer-asked-as-though-they-manufactured-it idioma: en categoria: sector-industria subcategoria: electrodomesticos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-019, KB-IU-009, KB-IU-012, KB-IU-031] citadoPor: [KB-IU-021, KB-IU-022, KB-LG-022] --- # The importer asked as though they manufactured it _You have no factory and the questions arrive as if you did. Between you and whoever made it lie eight thousand kilometres and an unanswered email._ **Responde a:** technical documentation for an imported product · asked for papers on a product i do not make · what to keep from a non-eu supplier · declaration of conformity for imported goods You buy a finished product abroad, bring it in and sell it. There is no machine in your warehouse: there are pallets, racking and a sales rep. **And yet when someone asks about that product, they ask you** — because you are the first link in the chain within their reach. Whoever made it is far away, in another jurisdiction and, very often, in another time zone with a different contact every six months. ## When the question arrives, and what answering it depends on | When | Who asks | What decides whether you can answer | | --- | --- | --- | | Before selling | A large customer | What you asked the supplier for when buying | | On arrival | The border | What travels with the shipment | | Months later | A customer or a review | What you kept about that specific shipment | | **Years later** | **A claim** | **Whether the supplier still exists and replies** | > [!IMPORTANT] > **The only moment you have leverage to demand documentation from your supplier is before you pay.** After that you are one more customer sending emails. Anything not asked for in the purchase order —the technical documentation, who signs it, in what language, how long it is retained, who to write to when their sales contact changes— is something you will later negotiate from a far weaker position, or reconstruct without them. ## What to hold per reference, not per supplier 1. **What documentation covers that specific reference** — Not the whole catalogue: catalogues change and so do references. 2. **Which shipments it applies to** — A document without a batch or a date cannot answer about a specific shipment. 3. **Who issued it and how to reach them again** — A person and an email, not just a company name. 4. **And when it expires or is superseded** — New versions do not announce that they have made the old one obsolete. > [!WARNING] > The costliest failure in this position: **filing documentation by supplier rather than by reference and shipment**. It works while you sell three things. The day a claim lands on a product sold two years ago, the question is not «what did this supplier send me?» but «what exactly covered what went out in that shipment?», and those two questions diverge the moment the supplier changed something along the way — which is the norm. > [!NOTE] > What responsibilities fall on whoever places a product on a market, what documentation must be producible, for how long and in what language **depends on the product and the market, and is settled by your adviser or the relevant body**. Here we cover the part that decides whether you can produce it: what you asked for, which shipment it belongs to, and whether you can find it two years on. **Is the documentation on the supplier's website enough?** To trade, perhaps. To answer about a shipment from two years ago, no: it changes without notice. **Do I need it translated?** It depends on the market and the product. Ask before buying, not after selling. **What if the supplier ceases to exist?** Then you have only what you kept. That is the whole argument for keeping it well. ## Ejemplos **A large customer asks for the technical documentation of a specific reference.** - Files documentation against the reference rather than the supplier → What is handed over covers the product sold, not the catalogue. **A claim arrives about a product sold two years ago.** - Keeps which document covered each shipment and from when → The answer uses what covered it then, not what is current now. **The supplier issues a new version and nobody notices until there is a problem.** - Keeps each version with its date instead of overwriting it → The old version stays available for what was sold under it. **Chasing documentation from the supplier costs weeks of email.** - Sends the request and chases on its own until it arrives → Follow-up stops occupying a person. **Documents arrive in several languages and formats per reference.** - Gathers everything for one reference in a single file → What is there and what is missing is visible at once. **The supplier's contact changes and nobody knows who to write to.** - Records who issued each document and how to reach them → The next request does not start by hunting for a contact. --- --- id: KB-IU-021 url: https://app.codecontract.io/help/manufacturing/the-distributor-who-only-resells-and-still-answers idioma: en categoria: sector-industria subcategoria: electronica audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-020, KB-IU-018] citadoPor: [KB-IU-022, KB-IU-024] --- # The distributor who only resells and still answers _You buy finished goods and sell them untouched. You are the only link the customer knows by name, and that is enough._ **Responde a:** distributor responsibility for the product · asked for documentation on goods i only resell · what a distributor should keep on file · customer asking for a certificate on a product i distribute Your work starts once the product already exists and ends when it goes out of the door to the customer. **You do not design it, make it or modify it** — and yet when something is asked, it is asked at your counter, because you are the only link the customer has in front of them. This position is always underrated for the same reason: doing nothing to the product looks like having nothing to show. ## What gets asked of you, ordered by what it costs to have | What they ask | Where it comes from | Cost of holding it | | --- | --- | --- | | What ships with the product | The supplier, at purchase | Low, if asked for at purchase | | Which version went to whom | Your own records | Low, if recorded at sale | | Documentation for an old reference | The supplier, months later | High: they must be tracked down | | **Tracing a batch to a customer** | **Cross-referencing both** | **Impossible if not done at the time** | > [!IMPORTANT] > **What sets you apart from every other position in the chain is that you are the only one who knows WHO each item went to.** The manufacturer knows what they made; the importer knows what they brought in; only you know what went out to which customer and on what date. Nobody else holds that, and it cannot be reconstructed afterwards — and it is precisely what is needed the day someone has to be warned. ## The minimum that holds this position up 1. **Ask for documentation when buying, not when selling** — It costs a line on the purchase order and saves a month of email. 2. **Record what went out, when and to whom** — Even without a batch number: the date and the customer are already a lot. 3. **File the supplier's documents by reference** — And keep the old versions when a new one arrives. 4. **Know who to warn if warning is needed** — That is the day everything above pays for itself. > [!WARNING] > The moment this position turns serious all at once is **when the manufacturer flags a problem and you must decide who to call**. If what went out is recorded, it is an afternoon's work and a list. If it is not, the only honest alternative is to warn every customer about everything, which costs the trust of people who had no problem at all. The difference between those two situations was decided months earlier, by recording or not recording what went out. > [!NOTE] > What specific duties fall on whoever distributes a product, what must be checked before selling it and how to act on discovering a problem **depends on the product and the market, and is settled by your adviser**. Here we cover the operational part: what to ask for, what to record, and what lets you warn whoever needs warning without warning everybody. **If I do not touch the product, do I have anything to keep?** Yes: what the supplier gave you and what you sold. Nobody else holds the second. **Do I need batch records if the product has no batch?** Record date and customer. It is less precise and still usable. **What if the supplier sends nothing?** That is a purchasing decision: ask for it on the order, or accept you will not have it. ## Ejemplos **The manufacturer flags a problem and you must decide who to call.** - Records what went out, when and to which customer → Those affected are warned instead of the whole customer base. **A customer asks for the certificate of something bought a year ago.** - Keeps documentation by reference and by version → What is handed over covered that sale, not today's. **Supplier documentation arrives loose by email and gets lost.** - Receives and files each document under its reference → It stops depending on searching the inbox. **Nobody knows whether a reference has all its documentation current.** - Shows what is missing per reference before anyone asks → The gap closes without a customer waiting on the phone. **Chasing the supplier for what was missed at purchase takes weeks.** - Chases automatically until the document arrives → The chase does not depend on someone remembering. **Two sales reps keep their certificates in different folders.** - Brings the documentation together in one shared place → The answer to the customer does not depend on who is in that day. --- --- id: KB-IU-022 url: https://app.codecontract.io/help/manufacturing/the-manufacturer-the-questions-come-back-to idioma: en categoria: sector-industria subcategoria: electrico audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-020, KB-IU-021] citadoPor: [KB-CN-034, KB-IU-031] --- # The manufacturer the questions come back to _You sold that four years ago and today you hear from someone who never bought from you. The chain sends its questions back to the start._ **Responde a:** how long to keep technical documentation · my distributors customer is asking me for papers · traceability of what i made years ago · which version of the product went to whom You are the start of the chain, and that carries a consequence that takes years to surface: **every question eventually comes back here**. The importer cannot answer alone, nor can the distributor, and when the chain runs out of answers it looks upstream. What arrives is not a sales enquiry but a specific request about something that left your plant when the product was a different one. ## What makes answering hard, and it is not a missing archive | What is asked | Why it is hard | What resolves it | | --- | --- | --- | | About one specific unit | It went out in a batch of a thousand | Knowing which version that batch carried | | About a discontinued product | It is no longer made | Keeping the documentation after the product dies | | From a customer who is not yours | They are not in your records | Being able to answer by product, not by customer | | **About a design change** | **It was three versions ago** | **Having each version dated and its period recorded** | > [!IMPORTANT] > **The technical file does not age with the product: it ages with the last unit sold.** It is the commonest error of perspective in this position. A reference is withdrawn from the catalogue, the folder is tidied away and the matter considered closed — but out there units are running, and a chain two or three links long will keep asking about them long after you stopped making them. ## What to decide once and apply always 1. **What is kept per version, and until when** — Counted from the last unit sold, not from the end of production. 2. **How to find which version a batch carried** — Without it, every question becomes a full investigation. 3. **Who answers when a stranger asks** — Your distributor's customer will write to you anyway. 4. **And what is handed over and what is not** — Deciding beforehand avoids improvising with sensitive material in front of you. > [!WARNING] > There is a specific and not obvious risk in this position: **answering with too much**. An urgent request arrives from someone you do not know, with a real problem, and the quick way out is to send the whole file. Inside go things that did not need showing —calculations, suppliers, tolerances— and that cannot be taken back. Having decided in advance what is handed over for each kind of question turns a decision under pressure into a procedure. > [!NOTE] > What technical documentation must be retained, for how many years, who may require its production and what part of it must be handed to a third party **depends on the product and the market, and is settled by your adviser or the relevant body**. Here we cover the organisational part: how to find it, how to know which version applies, and how not to hand over more than needed. **Can I archive everything once I stop making a product?** Archive yes, delete no. The chain keeps asking years afterwards. **Must I answer a customer who is not mine?** It depends, but they will reach you anyway. Better to decide in advance who answers and with what. **How do I know which version a batch carried?** Only if it was recorded at the time. Afterwards there is no way to deduce it with certainty. ## Ejemplos **A request arrives about a unit sold four years ago.** - Keeps which version covered each batch and from when → The answer comes from the archive rather than an investigation. **A product is discontinued and its documentation is filed without criteria.** - Sets retention counted from the last unit sold → What is still out there still has backing. **A customer of your distributor, unknown to you, writes in.** - Allows searching by product and not only by customer → It is answered without depending on who was invoiced. **Each version overwrites the previous one in the same folder.** - Stores versions with their dates instead of replacing them → You can say what applied at any given moment. **An urgent request is answered by sending the entire file.** - Controls which documents are shared and with whom → What was needed is handed over, not what sat beside it. **The distributor and the importer ask the same thing separately.** - Makes the document available to whoever needs to see it → The same question stops being answered twice. --- --- id: KB-IU-023 url: https://app.codecontract.io/help/manufacturing/the-batch-you-decide-yourselves idioma: en categoria: sector-industria subcategoria: cemento audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-014, KB-IU-008] citadoPor: [KB-IU-024] --- # The batch you decide yourselves _The line does not stop, so the batch is not set by the product: you set it. And its width is what it will cost the day something goes wrong._ **Responde a:** how to define a batch in continuous production · what batch width is reasonable · traceability in continuous manufacturing · how much product would i have to recall Your line runs without interruption for whole shifts. There is no piece, no unit, nothing you can pick up and call «this one». **The batch is a convention: somebody decided a batch is eight hours, or a silo, or a day** — and that decision, taken years ago for probably operational reasons, is what will determine how much product has to be touched the day a problem appears. ## What changes depending on where you draw the line | Batch width | Daily cost | Cost on the bad day | | --- | --- | --- | | One shift | More records | Contained to one shift | | One day | Fewer records | Contained to one day | | One week | Almost none | **A week of production** | | **Undefined** | **None** | **Everything out there** | > [!IMPORTANT] > **Batch width is an economic decision dressed as a technical one, and it is almost never taken looking at the scenario that matters.** It gets chosen for production convenience —what fits the shifts, the silos, the system— rather than by the question that should decide it: if something has to be isolated tomorrow, how much product do I want to be forced to touch? That question costs one meeting and is answered once. ## What must be reconstructable for each batch 1. **What went in: raw materials and their consignments** — If the output batch cannot be tied to the input ones, it traces nothing. 2. **What conditions applied while producing** — The readings you already take, tied to the batch rather than the day. 3. **Where it went: what shipped and to whom** — It is the half that almost always lives in another system. 4. **And what was changed mid-run** — A mid-shift adjustment splits the batch in fact, if not on paper. > [!WARNING] > The structural failure in this position is **that traceability breaks exactly at the system boundary**: production knows what was made and logistics knows what was shipped, but the batch and the delivery note live in different places and nobody has ever tied them together. While nothing happens, it does not show. The day you have to decide who to warn, that seam is precisely where everything tears, and rebuilding it by hand takes days you do not have. > [!NOTE] > How a batch must be defined for your product, what records must be kept and for how long, and what your certification scheme requires **depends on the product and the applicable scheme, and is settled by your adviser or certification body**. Here we cover the organisational part: how to tie inputs, conditions and outputs to the same unit so scope can be contained when needed. **Is a narrower batch always better?** It is dearer daily and far cheaper on the bad day. It is a decision, not a given. **Can I change the batch definition?** Yes, and it is worth revisiting. What does not work is having one nobody ever thought about. **What use is tracing if I cannot identify the product physically?** Containment. Without physical identification, records are the only thing that narrows scope. ## Ejemplos **A problem must be contained and the batch spans a whole week.** - Allows recording per unit rather than only per day → Scope narrows to what is actually affected. **Production and dispatch live in different systems.** - Gathers what was made and what shipped in one file → The batch can be followed through to the customer. **Shift readings are filed by day rather than by batch.** - Ties each record to the unit that traces → Conditions are consulted per batch. **A mid-shift adjustment is not reflected anywhere.** - Records changes with their time inside the batch → The real split of the batch is known. **A customer asks about a consignment delivered a year ago.** - Keeps the batch file with its date → It is answered without reconstructing anything. **Nobody knows which raw materials went into a given batch.** - Ties input consignments to the output batch → Tracing runs backwards and not only forwards. --- --- id: KB-IU-024 url: https://app.codecontract.io/help/manufacturing/turning-one-origin-into-a-hundred-orders idioma: en categoria: sector-industria subcategoria: papel audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-023, KB-IU-021] citadoPor: [KB-IU-025] --- # Turning one origin into a hundred orders _One reel comes in and a hundred orders go out. Every cut multiplies by a hundred the list of who would have to be called._ **Responde a:** traceability when cutting or converting material · one origin going to many customers · how do i know which customers got a material · converting reels into orders traceability You receive material in large format —reels, sheets, boards, sections— and your job is turning it into what each customer ordered. **You are the point where the chain fans out**: what comes through your door as one thing leaves as a hundred separate shipments to a hundred separate destinations. And that fan can only be walked backwards if somebody recorded it while opening it. ## How the count opens up | Stage | How many things there are | What must be known | | --- | --- | --- | | Receipt | One consignment | Where it came from | | Conversion | Many formats | **What came out of what** | | Dispatch | A hundred shipments | What went to whom | | **A query afterwards** | **One question** | **Walking it backwards** | > [!IMPORTANT] > **The point that decides everything is the cut, and it is exactly where least is recorded.** Receipt is nearly always logged, and so is dispatch because it has to be invoiced. What almost nobody ties is the middle link: which incoming consignment gave rise to which outgoing orders. Without that link you hold two correct lists and no way to get from one to the other, which is precisely what is needed when someone asks. ## The minimum to be able to walk it backwards 1. **Identify the consignment on receipt** — Using what the supplier gave you, not a fresh internal reference. 2. **Record which consignment each work order comes from** — That is the link, and it is usually a single field. 3. **Carry it through to the delivery note** — If it is lost at dispatch, all the previous work counts for nothing. 4. **And keep it once the order is closed** — Queries arrive when the order is already history. > [!WARNING] > The scenario you must be able to resolve is always the same: **the supplier flags a problem in a specific consignment**. At that moment the question is not whether your process is good, it is how many of your customers received something from it. If the link exists, it is a query and a list. If it does not, the only honest answer covers everything shipped over those weeks — which means calling customers who had no problem at all, a commercial cost that lasts years. > [!NOTE] > What traceability your product or certification scheme requires, what must be kept and for how long **depends on the sector and the customer, and is settled by your adviser or certification body**. Here we cover the organisational part: how to maintain the link between what comes in and what goes out without making it a separate job. **Do I need traceability if my product does not require it?** Required or not, it decides how many customers you have to call on the bad day. **What if I mix several consignments in one order?** Then record several. An order can have more than one origin. **Is the supplier's delivery note enough?** It is half of it. The other half is which orders came out of it. ## Ejemplos **The supplier flags a problem in a specific consignment.** - Allows querying which orders came out of that consignment → Those affected are called, not the whole customer base. **Receipt and dispatch are recorded, but the cut is not.** - Ties the work order to the incoming consignment → The two lists can be walked in both directions. **One order carries material from two different consignments.** - Allows associating more than one origin with the same order → The trace reflects what actually happened. **The consignment reference is lost when the delivery note is issued.** - Carries the reference through to the outgoing document → The link reaches the customer. **An order closes and its information stops being accessible.** - Keeps the file once the order is history → Late queries have an answer. **Reconstructing which customers got a material takes days.** - Gathers receipt, conversion and dispatch in one place → The query is resolved in minutes. --- --- id: KB-IU-025 url: https://app.codecontract.io/help/manufacturing/receiving-material-you-cannot-tell-apart idioma: en categoria: sector-industria subcategoria: vidrio audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-024, KB-IU-018] citadoPor: [KB-IU-028] --- # Receiving material you cannot tell apart _Two consignments of the same material look and feel identical. Once they meet in the warehouse, there is no separating them again._ **Responde a:** identifying identical material consignments · unmarked material traceability in the warehouse · mixing consignments in storage problem · knowing which consignment my stock came from You receive material with nothing written on it: sheets, sections, pellets, boards. Two deliveries of the same product, weeks apart and perhaps from different plants, **are physically indistinguishable the moment they are stacked together**. Each one's documentation arrived separately and is correct; the problem is that from the moment the material merges, that documentation can no longer be assigned to anything specific. ## Where the identity is lost | Moment | Is the consignment known? | What preserves it | | --- | --- | --- | | On the lorry | Yes | The delivery note | | At unloading | Yes, if someone looks | Recording it when it is put away | | Stacked with the previous lot | **No** | **Separating or marking it** | | **Consumed in production** | **No, and it does not come back** | **What was recorded at consumption** | > [!IMPORTANT] > **With indistinguishable material, traceability does not come from the material: it comes from the location.** That is the shift in thinking that is hard and that solves the problem. It is not about marking every sheet, but about knowing what is in each place and not mixing two consignments in one place without recording it. It is warehouse discipline, not a labelling system — which is why it works even when the material takes no marking at all. ## What sustains this in a real warehouse 1. **Locate by consignment at unloading** — Even if it is one bay and a label on the racking, not on the material. 2. **Record when two consignments share a place** — It will happen. What cannot happen is it happening unrecorded. 3. **Record where it was taken from at consumption** — That is the fact tying the warehouse to production. 4. **And review whatever has sat a long time** — Old material is always the worst identified. > [!WARNING] > The situation to avoid above all is **the remainder of an old consignment that nobody can date**. It turns up at the back, it looks like what is in front, and the reasonable thing at that moment —using it, it is perfectly fine— is also what breaks the trace of everything made from it. It does not need throwing away: it needs identifying before somebody decides to use it in a hurry on a Friday afternoon. > [!NOTE] > What identification and traceability your material or certification scheme requires, and what must be kept per consignment **depends on the product and the customer, and is settled by your adviser or certification body**. Here we cover the organisational part: how to preserve the identity of consignments the material itself does not distinguish. **Must I physically mark the material?** It is not always possible. Controlling the location always is. **What if two consignments end up together?** It happens. What matters is that it is recorded that they are together. **What about old unidentified remainders?** Identify them before someone uses them, not afterwards. ## Ejemplos **Two identical consignments are stacked together and become indistinguishable.** - Records which consignment goes in each location → Identity is preserved by the location. **Nobody knows which consignment yesterday's material came from.** - Records where material is taken from when used → The warehouse is tied to production. **An old remainder turns up that nobody can date.** - Flags what has sat too long without movement → It is identified before someone uses it in a hurry. **Each delivery's documentation is filed by supplier.** - Stores documents against the consignment received → The paperwork still points at something specific. **The supplier asks about a consignment delivered months ago.** - Keeps the receipt with its date and location → You can say what was done with it. **Nothing is recorded at unloading because the material carries no mark.** - Allows recording the receipt from the loading bay itself → The data is captured while it is still known. --- --- id: KB-IU-026 url: https://app.codecontract.io/help/manufacturing/declaring-what-left-the-plant idioma: en categoria: sector-industria subcategoria: petroquimica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-035, KB-IU-013] citadoPor: [KB-IU-027] --- # Declaring what left the plant _Once a year twelve months of scattered data must become a figure somebody signs. That somebody is you._ **Responde a:** annual declaration for an installation · gathering a year of data to declare · where the figures i declare come from · evidencing a declared figure years later Periodically a declaration must be filed: what was consumed, emitted, managed, produced. **You generate none of that data** — the plant generates it, different equipment and systems collect it, and some of it comes from a third party. Your job is to gather it, reconcile it and sign a figure that from that moment is the official version of what happened. ## Where each number you sign comes from | The figure | Who generates it | What backs it | | --- | --- | --- | | Own readings | Your equipment | The record, if retained | | Analyses | A laboratory | Their report, with its date | | Removals | An external contractor | **Their receipt, which can be late** | | **Estimates** | **You** | **The basis, if it was written down** | > [!IMPORTANT] > **What must be defensible is not the declared figure: it is how it was reached.** A later review rarely disputes the number itself; it disputes where it came from, what was included, what was estimated and on what basis. If the calculation lives in a spreadsheet made by somebody who has left, with unexplained columns, the figure can be perfectly correct and still be indefensible. ## What turns the declaration into a formality 1. **Collect during the year, not at the end** — What is asked for in January is scattered across twelve months of places. 2. **Store the evidence beside the figure** — The report, the receipt and the reading, not just the number. 3. **Write down the basis for anything estimated** — At the time, while someone remembers why it was estimated that way. 4. **And keep the declaration with its evidence** — It is reviewed years later, not the following week. > [!WARNING] > What most delays this position is **the figure that depends on a third party**: the receipt the contractor has not sent, the missing analysis, the laboratory certificate. It gets chased in January, with the deadline looming, and arrives when it arrives. Asking for it during the year —as it is generated, not at the end— is the only way to stop the deadline depending on somebody else's diary. > [!NOTE] > What declarations are mandatory for your installation, what data they include, what calculation or estimation methods are acceptable and how long the supporting evidence must be kept **is determined by the applicable rules and your authorisation, and settled by your adviser or the competent body**. Here we cover the organisational part: how to gather the year during the year and be able to explain the figure afterwards. **Do I only keep the filed declaration?** Also what backs it. That is what gets reviewed later. **How do I justify an estimate?** By writing the basis when it is applied, not when it is questioned. **What if a third party is late with their part?** Which is why it pays to request it during the year, with automatic chasing. ## Ejemplos **In January twelve months of scattered data must be gathered.** - Collects and files each figure as it is generated → The declaration is prepared without an annual campaign. **An external contractor's receipt is missing.** - Requests and chases automatically through the year → Third-party data arrives before the deadline. **A review asks where a figure came from.** - Stores the evidence beside the declared figure → The number's origin can be shown. **The calculation lives in a spreadsheet by someone who has left.** - Keeps the written basis with the file → The figure stops depending on one person. **A figure is estimated and nobody notes why.** - Allows recording the basis at the moment → The estimate is explicable years later. **The declaration is filed and no copy with its evidence is kept.** - Keeps what was filed and what supported it → The later review has something to answer with. --- --- id: KB-IU-027 url: https://app.codecontract.io/help/manufacturing/taking-away-what-somebody-else-generates idioma: en categoria: sector-industria subcategoria: residuos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-026, KB-IU-011, KB-IU-029, KB-NO-019] citadoPor: [KB-NO-020] --- # Taking away what somebody else generates _Your customer hands you something they want to stop answering for. The document you give back is all they will have._ **Responde a:** who issues the removal receipt · customer chasing a document for a collection · traceability of what was collected from each customer · managing collections from many customers You collect from your customers' premises something they want out of there, and in exchange you give them a document. **That document is the real product of your service** — the lorry is the visible part, but what your customer must keep for years, and what they will be asked for if anyone questions them, is the receipt you issue. ## What each part of your service is worth | What you do | What the customer sees | What they are left with | | --- | --- | --- | | Turning up | The lorry | Nothing | | Removing | The empty space | Nothing | | Treating | They do not see it | Nothing | | **Issuing the receipt** | **A document** | **Everything** | > [!IMPORTANT] > **A receipt that arrives late or incomplete turns a well-delivered service into a problem for your customer.** And it does so in the worst possible way: they no longer have what they handed you, they have already paid, and all they can show is whatever you send them. From their seat there is no difference between a service that was not performed and one that cannot be documented — and since that is the part they keep, it is also the part they judge you on. ## What sustains this across many customers 1. **The receipt going out with the collection** — The further apart in time, the more get lost on the way. 2. **Being consultable without asking you** — It saves half the calls you receive. 3. **Each customer seeing theirs and only theirs** — With a hundred customers that is confidentiality, not tidiness. 4. **And a record of what was sent** — «It never reached me» is the commonest complaint and the easiest to close. > [!WARNING] > The invisible work that eats this position's margin is **resending documents for old collections**. It is a task that appears in no quotation: scattered calls, from customers preparing a review who cannot find something from two years ago, handled by someone who has to search the archive. Multiplied across a large customer base it is a half-time job — and it almost entirely disappears if the customer can look it up themselves. > [!NOTE] > What documentation must accompany each collection, who must issue it, what data it includes and how long each party retains it **is determined by the rules applying to the material, and settled by your adviser or the competent body**. Here we cover the organisational part: how to issue, deliver and retain the receipt across many customers at once. **When should the receipt be issued?** As close to the collection as possible. Distance in time is what loses them. **Should I keep a copy too?** Yes, and you will be asked for it. The customer loses theirs before you lose yours. **How do I cut the resend calls?** By letting each customer consult theirs without asking you. ## Ejemplos **A customer asks for the receipt of a collection two years ago.** - Keeps each receipt tied to its customer and date → It is located without searching the archive. **The receipt is issued weeks after the collection.** - Allows issuing and delivering at the moment of service → The document does not drift from the service. **The customer says they never received a document.** - Keeps a record of what was sent and when → Delivery is demonstrable. **Resending old documents takes half a day a week.** - Lets each customer look up their own → The resend calls disappear. **With a hundred customers there is a risk of sending one's to another.** - Limits what each customer sees to their own file → Confidentiality does not depend on checking every send. **Receipts are filed by date rather than by customer.** - Organises documents by customer and by service → You search the way people ask. --- --- id: KB-IU-028 url: https://app.codecontract.io/help/manufacturing/working-with-the-customers-own-material idioma: en categoria: sector-industria subcategoria: mecanizado audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-017, KB-IU-025] citadoPor: [KB-IU-029, KB-IU-030] --- # Working with the customer's own material _The material arrives without an invoice and leaves as parts. While it is here it belongs to someone else, and whoever holds it answers for it._ **Responde a:** customer-owned material in my workshop liability · what to do with offcuts of someone else's material · documenting incoming customer material · customer claiming material that cannot be found Your customer sends the material and you provide the work. **That material was not sold to you**: it enters your premises, is stored alongside yours, is cut, transformed, and part of it becomes swarf or offcut. Throughout all of that it belongs to someone else, and its value can be several times your invoice for working it. ## What must be answerable at any moment | The question | When it arrives | What answers it | | --- | --- | --- | | How much of mine do you hold? | When the customer takes stock | Your goods-in and goods-out record | | Which heat is this from? | About a specific part | What was recorded on receipt | | Where is the leftover? | At the end of the order | What was agreed, if it was | | **What happened to the missing amount?** | **In a discrepancy** | **The record, or nothing** | > [!IMPORTANT] > **Someone else's material needs the same goods-in and goods-out control as your own, and almost never has it — precisely because it was not bought.** It does not come through purchasing, it generates no invoice, it does not appear in the accounting inventory. It arrives at the bay on the customer's lorry and, from then on, exists only if somebody chose to record it. When the discrepancy arrives, there is nothing to compare. ## What to agree and record 1. **What comes in, when and with what identification** — Using the customer's reference, not an internal one they will not recognise. 2. **What counts as acceptable wastage** — Agreed beforehand. Arguing at the end is arguing over someone else's money. 3. **Who owns the leftover and what happens to it** — It is the awkward conversation and it belongs at the start. 4. **And what is returned at the end** — With evidence of the return, not only of the parts shipped. > [!WARNING] > The point that generates most friction, almost always without bad faith on either side, is **the offcut that stays in the workshop**. To you it is a remnant taking up space that might serve another job; to the customer it is material they paid for and have not had back. Both are right from where they sit, and the only way it does not end in an argument is having decided it in writing before the first order, while nothing is yet at stake. > [!NOTE] > Who owns material held on deposit, what custody liability you assume, how it is treated for accounting and insurance purposes and what happens to leftovers **is determined by the contract and the applicable rules, and settled by your adviser**. Here we cover the operational part: how to record receipts, consumption and returns of something not in your inventory. **Must I inventory material that is not mine?** It is what lets you answer when the customer asks. And they will. **Can I use the leftover for another job?** The contract decides. What does not work is deciding it unilaterally afterwards. **How do I document a return?** Like a delivery: with evidence of what was returned and when. ## Ejemplos **The customer takes stock and asks how much of theirs you hold.** - Records receipts, consumption and returns per customer → You answer with a figure rather than an estimate. **A discrepancy appears and there is no record of the receipt.** - Captures the receipt at the loading bay itself → What came in is documented from day one. **There is an argument over who keeps the leftover.** - Keeps what was agreed with the customer's file → The conversation is settled by the agreement. **A part needs to be traced to the consignment it came from.** - Ties the customer's identification to what was made → Tracing runs back to the material received. **Leftover material is returned and nothing is recorded.** - Records the return the way a delivery is recorded → The return is demonstrable. **Third-party material is stored with your own and gets confused.** - Records the location of each consignment received → Each customer's material stays identifiable. --- --- id: KB-IU-029 url: https://app.codecontract.io/help/manufacturing/keeping-the-tooling-somebody-else-paid-for idioma: en categoria: sector-industria subcategoria: calzado audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-028, KB-IU-003] citadoPor: [KB-IU-027] --- # Keeping the tooling somebody else paid for _The customer paid for the mould and it sits in your plant. While orders keep coming nobody asks; the day they stop, they do._ **Responde a:** who owns the mould the customer paid for · customer moving tooling to another supplier · custody of moulds and dies · what to document about customer tooling Making your customer's product required specific tooling —a last, a mould, a die, a cutter— that they paid for and that sits here, in your plant, because that is where it is used. **It is theirs and you hold it**, and that combination runs without friction for years, as long as orders keep coming. The question surfaces exactly when they stop. ## The same object from both seats | What is at stake | To the customer | To you | | --- | --- | --- | | What it is | An asset they paid for | A production tool | | Where it should be | Wherever they say | Where it is used | | Who maintains it | Presumably you | Presumably it is charged for | | **When it gets discussed** | **When they want to move it** | **When they want to move it** | > [!IMPORTANT] > **Everything not agreed when the tooling was made gets negotiated the day the customer wants to take it away, which is the worst possible day to negotiate.** That day they are changing supplier —or considering it—, you are losing a customer, and on top of that you must agree who pays accumulated maintenance, what condition it is handed over in and what happens to modifications made along the way. None of those conversations goes well in that context. ## What is worth holding for each tool 1. **Who owns it and what exactly was paid for** — Tooling, design and modifications can have different owners. 2. **Where it is and in what condition** — With periodic checks: wear gives no warning until a part comes out wrong. 3. **What maintenance it has had and who paid** — It is half the argument on collection day. 4. **And what happens if the customer claims it** — Notice, condition and who bears transport. Agreed at the start. > [!WARNING] > The case nobody plans for is **the tooling of a customer who stopped ordering and said nothing**. It takes up space, generates no revenue, degrades, and nobody knows whether an order will ever come back. It cannot be scrapped because it is not yours; phoning to ask sounds like closing a commercial door. Over the years several of these accumulate, and deciding what to do with them is far easier if a period of inactivity and its consequence were agreed at the outset. > [!NOTE] > Who owns the tooling, what custody and preservation duties holding it entails, how it is treated for insurance and what may be done with what nobody claims **is determined by the contract and the applicable rules, and settled by your adviser**. Here we cover the organisational part: what to record about each tool so that collection day is a formality. **Can I refuse to hand over tooling?** The contract decides, which is why the contract should say. **Who pays for maintenance?** Whatever was agreed. If nothing was, it gets argued at the worst moment. **What if the customer disappears?** It is the commonest case and the least planned for. Agree an inactivity period. ## Ejemplos **The customer claims their tooling and it must be located and assessed.** - Records where each tool is and in what condition → The handover is prepared without searching the plant. **There is a dispute over who paid for a mould's maintenance.** - Keeps the intervention history per tool → The dispute closes on the record. **There is tooling belonging to customers who no longer order.** - Flags what has gone too long without use → The decision is taken before they pile up. **Nobody knows what modifications were made to a mould.** - Stores each change with its date and author → The current state is explicable. **A tool degrades and it is discovered through a bad part.** - Warns about periodic checks for each tool → Wear is caught before the defect. **What was agreed about the tooling sits in an old email.** - Files the agreement with the customer's record → What was agreed is found when it is needed. --- --- id: KB-IU-030 url: https://app.codecontract.io/help/manufacturing/holding-a-sample-somebody-entrusted-to-you idioma: en categoria: sector-industria subcategoria: biotecnologia audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-028, KB-IU-008] citadoPor: [KB-IU-006] --- # Holding a sample somebody entrusted to you _Something was entrusted to you for a specific use and a specific time. The hard part is not storing it: it is showing what was done with it._ **Responde a:** material transferred for a project what to document · material transfer agreement · traceability of received samples · what happens to the sample when the project ends You receive material from a third party —a customer, a hospital, an institute, another company— to do something specific with it. **It came with conditions**: what it may be used for, for how long, what happens to what remains and what may be published or communicated about the results. Those conditions were agreed once, at the start, and from then on the real work is demonstrating they were respected. ## What must be demonstrable, and it is not what it seems | What is asked | What is usually held | What is needed | | --- | --- | --- | | Did you receive it? | The signed agreement | It is usually there | | What was it used for? | The project's results | **The use, not only the result** | | Who handled it? | In the team's heads | A record per person | | **What remains and where?** | **An estimate** | **The actual inventory** | | **And the surplus?** | **It depends** | **What was agreed, done and recorded** | > [!IMPORTANT] > **The agreement is signed once and compliance must be demonstrable for years, including the parts performed at the very end.** That is the asymmetry in this position: an initial document generates continuing obligations —of use, of custody, of final disposition— that nobody rereads and that are only checked once the project has ended, the team has dispersed and what happened has to be reconstructed. ## What to record from receipt onwards 1. **What was received, how much and under what conditions** — With the agreement's terms linked, not in another drawer. 2. **Each use: who, when, how much and what for** — It is the record that almost never exists and always gets asked for. 3. **Where whatever remains is** — By actual inventory, not by what should remain on paper. 4. **And what was done at the end** — Return or final disposition, evidenced and dated. > [!WARNING] > The most fragile moment in the whole cycle is **the end of the project**, precisely because by then nobody is interested: the results are in, the team has moved on, and what remains of the material is a tube in a freezer. Obligations about final disposition are almost always breached there, with no decision taken at all — and it is the part of the agreement most often checked afterwards, because it is the only one with a date attached. > [!NOTE] > What may be agreed in a material transfer agreement, what custody, use and disposition obligations it creates, and what regime applies to associated data or to material of human origin **depends on the material and the applicable rules, and is settled by your adviser**. Here we cover the organisational part: how to record receipt, uses and disposition to demonstrate compliance years later. **Is keeping the signed agreement enough?** It is the start. What gets checked is what was done afterwards. **Must every use be recorded?** It is the record most often asked for and least often held. **What happens when the project ends?** Whatever the agreement says, and it must be demonstrable that it was done. ## Ejemplos **Questions arrive about what was done with material transferred three years ago.** - Keeps the record of uses alongside the agreement → It is answered from the history, not from memory. **The agreement sits in a drawer and its terms are not remembered.** - Links the terms to the material's file → The obligations live where the work happens. **Nobody knows how much of a sample actually remains.** - Records each consumption at the moment → The inventory is real rather than calculated. **The project ends and the final disposition is not on record.** - Warns about obligations with an attached date → Closing the agreement is performed and documented. **It is unclear who handled the material at each point.** - Stores author and date on every entry → The chain of custody can be reconstructed. **The team disperses and the knowledge goes with it.** - Keeps the file accessible independently of individuals → The project stays explicable afterwards. --- --- id: KB-IU-031 url: https://app.codecontract.io/help/manufacturing/making-something-that-will-last-thirty-years idioma: en categoria: sector-industria subcategoria: ferroviaria audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-022, KB-IU-006] citadoPor: [KB-IU-020] --- # Making something that will last thirty years _What leaves the plant today will still be in service after you have changed systems four times. The archive has to outlive all of them._ **Responde a:** retaining technical documentation for decades · obsolete component and its documentation · asked about a part from twenty years ago · migrating technical history to another system Your product is designed to be running twenty-five or thirty years from now. **Your information systems do not last five.** Over that span you will change document manager two or three times, design supplier at least once, servers several times, and at each of those changes somebody will decide —usually without much thought— what comes along and what stays behind. ## How long each thing lasts | What | How long it lasts | What happens to it | | --- | --- | --- | | The product in service | 25-30 years | It keeps generating questions | | The system holding its archive | 3-7 years | It gets replaced | | The file format | Variable | It may stop opening | | **The person who designed it** | **Less** | **Retires or moves on** | > [!IMPORTANT] > **In this position the archive is not a place where things are stored: it is something that must be actively migrated for decades.** That is a shift in thinking, not a technical matter. A passive archive —«it is on the server»— works while the server exists; afterwards nobody is responsible for it continuing to exist. And there is no warning: the history is lost silently and discovered when somebody looks for it, fifteen years later. ## What decides whether the archive arrives alive 1. **Every migration explicitly including the old material** — That is where it is lost. It must be a project task, not a footnote. 2. **Formats openable without the original software** — At least for what must be readable twenty years from now. 3. **Traceability not tied to one particular system** — The link between part, version and document has to travel. 4. **And keeping what others gave you** — Suppliers disappear before the product does. > [!WARNING] > The problem that always arrives and for which there is never an archive is **the obsolete component**. A supplier stops making something inside your product, it has to be substituted, and doing so requires knowing exactly what was there and why it was chosen. That information existed: it is in the design file from twenty years ago. Whether it can be opened decides whether the substitution is an engineering task or a full redesign. > [!NOTE] > What technical documentation must be retained, for how many years, under what conditions and what the applicable certification scheme demands **depends on the product and the sector, and is settled by your adviser or the relevant body**. Here we cover the organisational part: how to get an archive alive to a horizon of decades, across several system changes. **How long must it be kept?** Count from the last unit in service, not from the end of production. **What format is advisable?** One openable without the program that created it, at least for the essentials. **And when changing systems?** Make the history an explicit task of the migration project. ## Ejemplos **A component becomes obsolete and what was there must be established.** - Keeps the design file accessible over the years → The substitution starts from what was decided then. **A system change leaves the history behind in the old one.** - Keeps the archive independent of the system of the day → The migration does not cut the product's history. **Questions arrive about a unit made twenty years ago.** - Stores which version covered each batch → There is an answer instead of an investigation. **Documentation from a supplier that no longer exists is missing.** - Keeps what third parties provided as your own → The supplier closing does not leave you with nothing. **Versions overwrite each other in the same folder.** - Stores each version with its period of validity → You can say what applied at each moment. **The designer retires and their knowledge was never written down.** - Keeps the file independent of individuals → The departure does not take the explanation. --- --- id: KB-CS-001 url: https://app.codecontract.io/help/construction/subcontractor-document-control idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-TL-001, KB-TL-004, KB-SC-001] citadoPor: [KB-CS-002, KB-CN-005, KB-CS-039, KB-CN-016, KB-CN-018, KB-CF-001, KB-CS-007] enLaApp: https://app.codecontract.io/trackline/schemas --- # Subcontractor document control on site _Collect each subcontractor's paperwork before they set foot on site, and let it expire on its own._ **Responde a:** subcontractor document control · how to collect health and safety paperwork from a subcontractor · contractor compliance documentation · check that subcontractor workers have valid training · software to manage construction site documentation On a site with six subcontractors and forty workers, health and safety paperwork means about two hundred documents that expire on different dates and arrive by email, by WhatsApp and by hand. The problem is not storing them: it is knowing, on an ordinary Tuesday, whether the person welding on the third floor has valid training. **En corto** - Asked for once per subcontractor, and the platform chases what is missing. - Each document carries its expiry date and warns before it lapses. - Nobody sets foot on site until their file is complete. - On inspection day the file is complete, with a date on every delivery. **The subcontractor onboarding circuit** — Site access is conditional on the file being complete, and expiry is tracked automatically. ## What to ask for, and in what order It is worth splitting into three blocks, because they are three different moments with three different counterparts. Asking for everything at once is the fastest way to receive nothing. | Block | What you ask for | From whom | | --- | --- | --- | | Company | Social security registration, liability insurance, tax clearance certificate, risk assessment | The subcontractor's manager | | Workers | Safety training, medical clearance, PPE handover record, individual registration | The same manager, one per person | | Machinery | CE marking, last maintenance record, insurance and operator licence | Whoever supplies the equipment | _The three blocks as phases: the workers phase does not open until the company is approved._ ## What it actually prevents - Someone walking on site with lapsed insurance and nobody noticing until there is an incident. - Losing a morning before every inspection gathering paperwork from three different inboxes. - Expiry dates tracked by a spreadsheet somebody has to remember to open. - Arguing with a subcontractor about whether they sent a certificate: the delivery date is logged. > [!WARNING] > The most commonly forgotten piece is expiry. A tax clearance certificate is valid for three months: with no expiry alert, by the second site of the year it is no longer valid and the file still looks complete. ## How to set it up 1. **Create a "Subcontractor onboarding" process with the three phases** — Designed once. After that, onboarding a new subcontractor is two clicks. 2. **Mark as mandatory only what genuinely blocks access** — Mark everything and the file stalls on a document that never stopped anyone entering. 3. **Set expiry dates on the documents that have them** — Insurance, tax clearance certificates and training. The alert fires before it lapses, not after. 4. **Run the process when hiring, picking the site folder** — One folder per site, one file per subcontractor inside. That is what turns an inspection into five minutes. ## Frequently asked questions **Does the subcontractor have to register for anything?** No. They get a link by email or WhatsApp, upload their documents from a phone, and that is it. No sign-up, no password. **Can I reuse a subcontractor's paperwork on another site?** Yes. What does not change — insurance, social security registration — is provided once and referenced; site-specific items are requested again. **What if a worker joins mid-project?** They are added to the running file without rebuilding anything, and the request reaches the subcontractor's manager. **Does it work for contractor coordination requirements?** That is exactly the case: it gathers, dates and retains the documentation that has to be exchanged, and records when each item was handed over. **How do I prove to an inspector that I had everything?** Every delivery is dated. If you also certify the closed file, a third party can verify the date without taking your word for it. ## Ejemplos **A construction company with four active sites gets an unannounced inspection at the Valencia one.** - Opens that site's folder - Shows each subcontractor's file with the delivery date of every document - Checks on the spot that no training has lapsed → The inspection is resolved on site, without calling the office or asking for time to produce paperwork. **A subcontractor arrives on site without current documentation.** - Checks their status before authorising entry → The gap shows before the gate. **A new worker arrives on the same day.** - Checks per person what is missing → Onboarding is resolved before access. **A document expires mid-project.** - Records expiries per company and per person → The warning arrives before it bites. **Chasing twelve subcontractors occupies a person.** - Requests and chases automatically → That person reviews instead of nagging. **The client asks who was on site on a specific day.** - Checks the record of authorised access → You answer using that day's date. --- --- id: KB-CS-015 url: https://app.codecontract.io/help/construction/civil-works-and-public-tenders idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CS-016] citadoPor: [KB-CN-009] --- # Civil works and public tenders _Documentation reviewed by a public authority, on deadlines that are not negotiable._ **Responde a:** documentation for a public tender · technical and financial standing tender · joint venture documentation · contractor classification civil works In public tendering, the difference from private work is not the volume of paperwork: it is that someone else sets the deadline and it does not move. Late means absent, and the documentation comes from third parties who do not share your urgency. ## The three modules, each in its moment | Moment | Module | For what | | --- | --- | --- | | Preparing the bid | Trackline | Gathering standing, certificates and documents from joint-venture partners | | Signing the consortium agreement or the bid | Consigne | Several companies signing, in order if a signatory validates last | | Keeping what was submitted | SmartCheck | Certifying the file exactly as submitted, with its date | > [!IMPORTANT] > Certifying what was submitted on the same day has a concrete purpose: if there is later an appeal or a dispute about what was handed in, you hold the exact set with a third party's date, not a folder you could have touched afterwards. ## Frameworks cited in this area Public procurement rules, contractor classification and standing, and — once work starts — contractor safety coordination and construction health and safety regulation. What each tender document requires is stated in that document, and the specific obligations come from your adviser: this only explains how to have the paperwork ready and dated. > [!WARNING] > Documentation from consortium partners comes from people who do not answer to you. It is the case where asking two weeks ahead with automatic reminders shows most, because the alternative is phoning around in the final three days. > [!NOTE] > Saving each tender's file as a template saves most of the work on the next one: what gets asked for changes less than it seems. **Can I give the authority access?** Submission normally goes through their platform; this is for having it gathered and proven beforehand. **What if a consortium partner does not deliver?** The case shows it with a name and a date, which is what lets you chase it internally. **Does it help justify delivery afterwards?** The dated history is exactly what later checks ask for. ## Ejemplos **A contractor bids on four tenders a quarter and the final 72 hours are always a scramble.** - Builds the tender file as a template - Requests partner documents two weeks ahead with reminders → Reaches the deadline with the file complete, and certifies the submission the same day. **Tender documentation is prepared in the final week.** - Gathers what repeats into one file → The second tender costs half. **A document is missing on submission day.** - Checks what is missing in advance → The gap closes with time to spare. **A certificate expires just before the deadline.** - Records expiries with a warning → Renewal happens before the tender. **Each tender asks for the same document in another format.** - Keeps the original and adapts on submission → The underlying work happens once. **The contract is awarded and what was submitted must be evidenced.** - Keeps what was submitted, with its date → You answer with what was handed in then. --- --- id: KB-CS-016 url: https://app.codecontract.io/help/construction/residential-building-and-handover idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CS-017, KB-CN-009] citadoPor: [KB-CS-015, KB-CN-001, KB-CN-002, KB-CN-004, KB-CN-006] --- # Residential building and handover _From the building file to the keys, with buyers who are not professionals._ **Responde a:** housing handover documentation · digital building file · property handover certificate · new-build aftersales Residential building adds an actor other construction does not have: the buyer, who is a private individual, does not read technical documentation, and will dispute the finishes two years later. That changes what has to be proved and how it has to be written. ## The three modules on a development | Phase | Module | For what | | --- | --- | --- | | Subcontractors and supplies | Trackline | Company, personnel and materials documentation | | Handover to the buyer | Consigne | Handover certificate and key receipt, signed by the buyer | | Condition at handover | SmartCheck | Certified photos of each home, on the day it is handed over | > [!IMPORTANT] > Certified photos from handover day are what decide an aftersales claim. Without them, telling a construction defect from later damage caused by the buyer is one person's word against the other's. ## Frameworks cited Building regulation and the building file, new-build warranties, and consumer protection rules in dealings with the buyer. What must be handed over and within what periods depends on your case and your region; ask your adviser. What matters here is that all of it is handed over once and you must be able to prove it was. > [!WARNING] > The handover certificate signed by the buyer is also the document that fixes when warranties start running. Having it signed with a certified time avoids the argument about the date, which is the first one to appear. > [!NOTE] > Handing over the building file digitally, with a signed receipt, also solves the perennial problem: the buyer who says three years later that they never received it. **Can the buyer sign from a phone?** Yes, and it is usually easiest on handover day. **What if there are two owners?** Both as signers, in parallel. **Does it help with aftersales?** It is what lets you scope what was a defect and what was not, with dates. ## Ejemplos **A developer receives aftersales claims for damage that was not a construction defect.** - Certifies photos of each home on handover day - Signs the handover certificate with the buyer → Claims are settled against the dated photos, with no surveys. **Handover arrives and documentation from several trades is missing.** - Requests documentation as each trade finishes → It is chased while the trade is still engaged. **A hundred buyers ask about their home.** - Organises the file per unit → You answer in the terms the question is asked. **An owner says they never received their documentation.** - Records what was handed to each and when → Handover is demonstrable. **The same issue appears in several homes.** - Views issues together by development → The pattern shows before the fourth visit. **A complaint arrives two years later.** - Keeps the file beyond handover → The warranty period is faced with the record from then. --- --- id: KB-CS-017 url: https://app.codecontract.io/help/construction/installation-and-maintenance-firms idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CS-010, KB-CN-002] citadoPor: [KB-CS-016, KB-CS-029, KB-CN-003, KB-CN-019] --- # Installation and maintenance firms _Many small jobs, each with its own certificate and signature._ **Responde a:** installation certificates · job sheets signed by the client · preventive maintenance documentation · installer certificates and inspections An installer does not have the big-project problem — few enormous files — but the opposite: hundreds of small jobs a year, each with its sheet, its certificate and its signature. What does not scale here is paper. ## The three modules day to day | What | Module | When | | --- | --- | --- | | Company documentation to be allowed on site | Trackline | Once per client, plus renewals | | Job sheet and client sign-off | Consigne | On every job, from a phone | | Condition before and after | SmartCheck | When a dispute is plausible | ## What changes most: signing on site Sign-off captured on the spot, from the technician's or the client's phone, avoids the usual circuit: paper sheet, gets wet or lost, chased a month later, and you end up invoicing without a sign-off. > [!IMPORTANT] > Installation certificates and periodic inspections expire and are typically required at inspection. Marking them with their expiry is what turns the archive into something that warns you; which inspections apply to each installation comes from sector regulation and your adviser. > [!WARNING] > If the technician signs on the client's behalf "because they were not there", the sign-off is worthless and creates a bigger problem than it solved. Let whoever receives the work sign, even if it is the next day from their own phone. > [!NOTE] > With many identical jobs, the template is where the saving is: the sheet goes out with two fields filled and the scope already written. **Does it work without signal on site?** The technician can send it once back in coverage; the client signs from their own phone when it arrives. **Can photos be attached to the sheet?** Yes, and in installations that is usually what prevents the argument. **What about scheduled maintenance?** Built as a recurring process, with its expiry alert. ## Ejemplos **An installer with 400 jobs a year loses paper sheets and invoices without sign-off.** - Sends the sheet for signature from a phone on completion - Attaches photos of the installation → Invoices stop being disputed over work nobody signed for. **Five clients ask for the same documents through five portals.** - Keeps a single current original → All five are answered without redoing the work. **A technician is stopped at the gate over their training.** - Warns about expiries per person → Renewal happens before the rota. **Equipment goes on site and its documentation sits elsewhere.** - Stores equipment documentation with the equipment → What travels is found where it is. **The job sheet reaches the office days later.** - Captures the sheet at the job itself → The month closes on what happened. **A client asks you to evidence an intervention from a year ago.** - Keeps the history per client and installation → You answer without reconstructing. --- --- id: KB-CN-001 url: https://app.codecontract.io/help/construction/document-control-in-construction idioma: en categoria: sector-construccion subcategoria: facility audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CS-016] citadoPor: [KB-CN-003, KB-CN-004] --- # Document control in construction _People coming and going daily, and a liability that cannot be subcontracted._ **Responde a:** construction document control · subcontractor documentation construction · contractor safety coordination · where to start with site documentation Construction has the hardest combination: many different people, coming and going weekly, working somewhere mistakes genuinely hurt. And the duty to check who enters is not subcontracted along with the work. ## The three levels to cross-check | Level | Documentation | How often it changes | | --- | --- | --- | | The subcontracted firm | Insurance, tax clearance, certificates | Annual, and it expires | | Each worker | Training, medicals, authorisations | Changes with every new person | | Each machine | Conformity, inspections, authorisation to use | It travels between sites | > [!IMPORTANT] > The cross-check between the three is what decides whether someone can enter today. A firm with everything in order and a worker with expired training is exactly the case examined after an accident, and the one no folder solves. ## Why spreadsheets break here sooner than anywhere Because status changes daily. The list someone updated on Monday no longer tells the truth on Wednesday, and the supervisor opening the gate is not in the office where that list lives. **En corto** - Status recalculates itself when something expires. - It is checked from a phone, at the gate. - Each branch — civil works, building, installations — adds its own on top. > [!WARNING] > Expiry warnings have to come with a long margin. Renewing training means arranging a course, and fifteen days does not do it: sixty does. > [!NOTE] > If you are audited on contractor safety coordination, this cross-check is exactly the file requested. Building it properly serves both purposes. **What about self-employed contractors?** Same as a firm: their own case with their documents. **Can I give the safety coordinator access?** Yes, read-only and scoped to that site. **Does it work across several sites?** One case per site, and machines travel with their own. ## Ejemplos **A contractor tracks nine subcontractors in a spreadsheet updated by one person.** - One case per subcontractor, with workers and machines inside - 60-day warnings → The supervisor checks at the gate from a phone, and the spreadsheet stops being the only place the truth lives. **Each project keeps its papers its own way.** - Uses the same file structure for all → The answer does not depend on which project is asked about. **The site manager carries the documentation on their phone.** - Stores captures in the project's file → The record survives a change of personnel. **At close-out, documentation from months back is missing.** - Requests as the event happens, not at close-out → Close-out becomes a formality. **A subcontractor comes in without being current.** - Checks the status before authorising → The gap shows before the gate. **A client asks you to evidence something from a finished project.** - Keeps the file beyond the end of works → The warranty period is faced with the record. --- --- id: KB-CN-002 url: https://app.codecontract.io/help/construction/refurbishment-and-renovation idioma: en categoria: sector-construccion subcategoria: rehabilitacion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-016, KB-CS-029] citadoPor: [KB-CS-017] --- # Refurbishment and renovation _Small jobs, many at once, and clients living on site._ **Responde a:** refurbishment documentation · works in residential buildings documentation · renovation grant justification · trades documentation on a refurbishment Refurbishment combines the worst of two worlds: construction documentation plus a client who is a private individual or a residents' association, who neither knows the sector nor has any reason to. And often with a grant involved that has to be justified months later. ## The four fronts | Front | What moves | Module | | --- | --- | --- | | Trades coming and going | Their documentation, each with their own | Trackline | | The client or association | Quote, acceptance, sign-offs | Consigne | | The building's condition | Before, during and after | SmartCheck | | The grant, if any | Dated execution evidence | SmartCheck during the works | > [!IMPORTANT] > Prior condition prevents the most arguments and is the most forgotten. Refurbishment works on something that already existed and almost always had defects: without dated before photos, any pre-existing crack ends up being yours. ## A private client changes the rules They do not read technical documentation, cannot tell one trade from another, and will remember what they were told verbally. That is why a signed quote with the scope inside is worth more here than on any other kind of works: it is the only thing fixing what was included and what was not. **En corto** - Quote signed before starting, with the scope written down. - Any change in a signed amendment, not in a message. - Sign-off on completion, before invoicing. > [!WARNING] > In residents' associations, whoever signs must be able to sign for the association. An agreement with the chair without a members' resolution is exactly what gets disputed when the levy arrives. > [!NOTE] > If you run several refurbishments at once, building them as one process makes the fifth cost a fraction of the first. The scope changes; the list of trades and documents, little. **What about small one-day jobs?** A signed quote and sign-off still pay off; the rest is overhead. **How do I justify a grant?** By certifying evidence during the works, not gathering it at the end. **Does it help with communications to the association?** Important communications are worth certifying on the day they are made. ## Ejemplos **A refurbishment firm disputes with a client whether a crack was caused by the works.** - Retrieves the certified photos of the prior condition → The crack was already there, the argument ends in an afternoon, and the repair does not come out of their pocket. **Something unforeseen appears on opening a wall.** - Records the finding with a photo at the moment → The extra cost is justified by what was seen. **The client says it was already like that.** - Captures the condition before starting → What was found is distinguished from what was done. **Changes are agreed verbally during the works.** - Puts each change on record in writing → The final invoice surprises nobody. **Work happens in an occupied home.** - Records the condition of what is not being touched → Other people's damage is not inherited. **At the end there is a dispute about what is outstanding.** - Runs the snagging list with status → Close-out advances on data. --- --- id: KB-CN-003 url: https://app.codecontract.io/help/construction/building-maintenance-and-facility-management idioma: en categoria: sector-construccion subcategoria: facility audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-001, KB-CS-017] citadoPor: [KB-CN-007, KB-CS-034, KB-CN-013] --- # Building maintenance _Many small contractors entering an occupied building, all year round._ **Responde a:** maintenance contractor documentation · controlling company access to a building · preventive maintenance records · facility management documentation Maintenance is construction inverted: instead of many people in one place for months, it is few people from many companies coming and going all year, in a building where people are also working or living. ## What makes it different **En corto** - Many small contractors, each with their speciality. - Frequent short visits, sometimes unannounced. - And building users with nothing to do with the works. | What is controlled | How often | Who checks | | --- | --- | --- | | Each company's documentation | At onboarding and annual renewal | Whoever contracts | | Training of each technician entering | Per person, and it expires | Whoever opens the door | | Mandatory building inspections | On their own schedule | The building manager | | Job sheets for each visit | Every visit | Whoever receives the work | > [!IMPORTANT] > The second row is what fails and carries most consequence: whoever opens the door to a technician is rarely whoever contracted their company, and has no way of knowing whether that particular person may do that work. Being able to check from a phone at the entrance is what solves it. ## Building inspections Lifts, fire protection, thermal installations, water safety where applicable: each with its own frequency and its own company. It is the set that scatters most, because each inspection belongs to a different contractor and the calendar lives in one person's head. > [!WARNING] > If you manage third parties' buildings, inspection documentation is the first thing you will be asked for when there is an incident, and the first thing their insurer will ask for too. > [!NOTE] > One case per building with its contractors and inspections inside turns "is everything current in this property?" into an answer rather than an afternoon of phone calls. **What about urgent out-of-hours callouts?** The job sheet is signed from a phone the same; the company's documentation was already checked. **Does it work across several buildings?** One case per property, with contractors shared. **Can I give the owner access?** Yes, read-only and scoped to their building. ## Ejemplos **A property manager does not know whether today's technician has current training.** - One case per building, with technicians as participants - Checking from a phone at the entrance → Whoever opens the door decides with the fact in front of them rather than trusting the contracted company. **A building is inherited with no asset inventory.** - Builds the inventory in the first weeks → Maintenance is planned on data. **Calendar inspections all fall due at once.** - Warns about each due date in advance → The calendar spreads out. **A unit still under warranty is repaired.** - Records which warranties are live → The avoidable cost is avoided. **The history lives on paper job sheets.** - Stores each intervention in the building's file → Knowledge stops being personal. **The contract ends and years of work must be handed over.** - Keeps the complete, exportable history → The handover takes hours. --- --- id: KB-CN-004 url: https://app.codecontract.io/help/construction/property-development-end-to-end idioma: en categoria: sector-construccion subcategoria: promocion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-016, KB-CN-001] citadoPor: [KB-CN-006, KB-CN-017] --- # A development, from land purchase to handover _Two or three years, many actors, and documentation that outlives all of them._ **Responde a:** property development documentation · developer building file · housing handover documentation · new build warranty documentation A development lasts two or three years and passes through designers, contractors, subcontractors, sales agents, buyers and finally a residents' association. Almost nobody is there from start to finish — except the documentation, which has to outlive all of them. ## The four phases and what accumulates in each | Phase | What documentation | Who will ask for it later | | --- | --- | --- | | Land and permits | Title, permits, conditions | The buyer, the bank, the association | | Design and contracting | Design, contracts, insurance | The insurer if there is a claim | | Construction | Subcontractors, materials, controls | Whoever claims a defect | | Handover | Building file, certificates, warranties | Each buyer, for years | > [!IMPORTANT] > The fourth column changes how everything before it is stored. None of this is filed for you: it is filed for someone who will ask for it in three, five or ten years, when whoever assembled it has left the company. ## What gets lost most **En corto** - Phase one material, because it seems irrelevant once building starts. - Material certificates, which arrive piecemeal over months. - And what was handed to each buyer, poorly remembered three years on. > [!WARNING] > Handing over the building file without a signed receipt is the error that reappears most: three years later a buyer says they never received it, and without a receipt the argument has no way out. ## What must be answerable years later Who executed each part, what material was used, what was handed to whom and when warranties started running. All four are answered with dates or not at all, and all four arrive when nobody remembers. > [!NOTE] > If you run several developments, building them as one process makes the third cost a fraction. What changes is the land and the buyers; the documentary skeleton, little. **Can I give the residents' association access at the end?** Yes, scoped to what belongs to them as owners. **And the contractor during the works?** Scoped to their part and with an end date. **How long must it be kept?** New-build warranty periods are long; confirm with your adviser. ## Ejemplos **A developer receives a claim three years on and cannot find the certificate for the material used.** - Builds the next development as a process, with certificates linked to each work package → The next claim is answered within the hour instead of absorbed for lack of proof. **The development advances and each stage files its papers separately.** - Uses one file per development → There is one picture from start to finish. **At handover, documentation from the construction stage is missing.** - Requests as the event happens → Handover does not uncover months-old gaps. **Each trade delivers whenever they remember.** - Requests and chases automatically → The final month goes on reviewing. **Buyers ask and there is no file per home.** - Also organises by unit → You answer the way people ask. **Years later a warranty claim arrives.** - Keeps the file beyond handover → The warranty period is faced with the record. --- --- id: KB-CN-005 url: https://app.codecontract.io/help/construction/health-and-safety-what-gets-signed-on-site idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CS-001] citadoPor: [KB-NO-013, KB-CN-011, KB-CR-016, KB-CN-015, KB-CN-016] --- # Health and safety: what gets signed on site _Minutes, acknowledgements and equipment handovers: papers that only count if dated and signed by the right person._ **Responde a:** site health and safety paperwork · safety plan acknowledgement form · signed ppe handover · contractor coordination on construction sites Site safety generates a layer of paperwork nobody enjoys and that, when something happens, is the first thing examined. And it nearly always fails the same way: the document exists but not the proof it reached the right person before the work. ## The four papers always requested | Document | Who signs it | When it must exist | | --- | --- | --- | | Safety plan acknowledgement | Every company entering | Before setting foot on site | | Task-specific information and training | Every worker | Before starting their task | | Protective equipment handover | Every worker | The day of handover, not later | | Coordination meeting minutes | Those attending | At every meeting, with the list | > [!IMPORTANT] > The third is the one most often falsified without meaning to. Equipment is handed over on the spot and the paper signed weeks later, in bulk, dated the day of signing. That document does not prove what it should, and whoever reviews it will notice. ## How to close it without chasing anyone 1. **Sign on a phone, at the moment** — Handover and signature happen together, which is what makes it valid. 2. **Make the plan acknowledgement an access requirement** — If people can get in without it, they will. 3. **Close the minutes as the meeting ends** — With actual attendees, not the invitation list. 4. **And hang everything off the site, not a folder per document type** — When they ask about an accident, they will ask by site and day. > [!WARNING] > Watch plan revisions. If the plan changes and companies had acknowledged the earlier version, a new acknowledgement is needed: the signed document points at a specific version and that one is no longer current. ## What is asked for after an accident **En corto** - Who was on site that day and for which company. - What training that person held for that task. - What equipment had been issued to them and when. - And what was discussed at the last coordination meeting. All four are answered in minutes if the site is a file, and in days if it is a cabinet. The difference is not having the papers: it is being able to line them all up against a date. > [!NOTE] > This sits alongside what you already require from subcontractors (insurance, contributions, fitness to work). It is the same expiring-documentation mechanic, except this is signed on site rather than in the office. **Is a phone signature valid for this?** Yes, and it also carries date and time, which paper does not. **What if the worker has no phone?** They can sign on the supervisor's device; what matters is that it happens at the moment. **How long must it be kept?** Years. Liability for an accident does not lapse quickly. ## Ejemplos **A builder signs equipment handovers in bulk at month end.** - Moves signing to a phone at the moment of handover - Links each signature to the site and the worker → Every handover is evidenced with its real date and stops being a weak point in an inspection. **A document is signed on site and stays in the hut.** - Captures it at the moment of signing → The paper stops being the only copy. **Somebody new joins and signs days later.** - Checks what is missing before authorising access → What is signed precedes entry. **Nobody knows who has signed what.** - Checks the status per person → The chase is aimed. **The document is updated and there are signatures on the old version.** - Keeps each version with its signers → You know who signed which version. **A review asks about a specific day.** - Checks what was signed on that date → You answer from the record. --- --- id: KB-CN-006 url: https://app.codecontract.io/help/construction/handover-documentation-and-warranties idioma: en categoria: sector-construccion subcategoria: promocion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-004, KB-CS-016] citadoPor: [KB-CN-008, KB-CN-009, KB-CN-010, KB-CN-012, KB-CN-013, KB-CN-017] --- # Handover documentation and warranties _What has to be handed over at the end, and why it is gathered during rather than after._ **Responde a:** site handover documentation · what the building manual contains · installation warranties at completion · as-built drawings and final certificates Completion is the moment when everything generated over two years is demanded at once: installation certificates, material warranties, as-built drawings, test records, manuals. And whoever gathers it at the end discovers half of it belonged to a company that got paid and left. ## Why it always jams the same way | Document | Who holds it | When it vanishes | | --- | --- | --- | | Installation certificates | The installer | When their part finishes, months earlier | | Material warranties | The supplier or buyer | When that person moves project | | As-built drawings | The engineers or site manager | When they move site | | Test records | Whoever ran them, sometimes only on paper | When the site office is dismantled | > [!IMPORTANT] > All four share something: **they exist while the work is fresh and evaporate when that trade leaves site.** Asking for them at the end means asking the worst person at the worst moment. ## The rule that fixes it Each trade hands over its documentation **when its part finishes, not when the project finishes**. And their final payment application closes with it delivered. It is the only lever that truly works, and it requires chasing nobody. 1. **Define the list per trade at contracting** — In the contract or order itself, not in a last-minute email. 2. **Open their folder from day one** — So that handing over means uploading, not preparing a package. 3. **Tie financial closure to delivery** — It is what turns a request into a priority. 4. **And review as each trade finishes, not at the end** — A wrong certificate is fixed in a week while they are still there; in a year, it is not. > [!WARNING] > Beware accepting "I'll email it to you". What arrives by email to one person disappears with their inbox: if they move site or company, the completion documentation stayed in a mailbox nobody opens. ## What the client takes away **En corto** - An ordered set, not a folder with two thousand loose files. - With live warranties identified and dated. - And in a form they can consult without depending on you. That last point serves you too: a handover the client can navigate alone generates far fewer calls over the following two years. > [!NOTE] > Warranties are documents with expiry dates like any other. Handed over with their dates, whoever receives the building can see what is still covered without opening every PDF. **What if a trade no longer exists?** Hence collecting as their part ends. After that you can only reconstruct what is available. **Does it apply to small refurbishments?** Yes, and it is easier: fewer trades and less turnover. **Who keeps it afterwards?** The client, and you should keep a copy for your liability period. ## Ejemplos **A developer gathers handover documentation three months after completion.** - Switches to collecting per trade as each part closes - Ties the final payment application to document delivery → The next development hands over the complete set on the day of completion. **Close-out gathers months-old material at the end.** - Requests as each trade finishes → Close-out becomes a formality. **A trade has been paid and does not respond.** - Chases before certifying their work → You chase while there is still leverage. **The list of what is missing appears at the end.** - Shows what is missing from day one → The gap is visible while it can be closed. **Handover happens with a gap and no record of chasing.** - Keeps what was requested, from whom and how many times → The trail is the defence. **Under warranty, close-out documentation is requested.** - Keeps the file beyond handover → You answer with the record from then. --- --- id: KB-CN-007 url: https://app.codecontract.io/help/construction/works-in-premises-that-stay-open idioma: en categoria: sector-construccion subcategoria: noresidencial audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CN-003] citadoPor: [KB-CN-019] --- # Works in premises that stay open _Refurbishing a shop, hotel or plant without closing: time-slot permits and people entering every night._ **Responde a:** shopping centre fit-out documentation · night work permits in open premises · refurbishment without closing paperwork · contractor access to an occupied building Refurbishing something that stays open adds a layer a normal site does not have: every entry is limited to a slot, the landlord has its own rules, and whoever comes in tonight may not be who came in yesterday. Documentation stops being a prior requirement and becomes a daily condition of access. ## What changes versus a closed site | Aspect | Closed site | Premises in use | | --- | --- | --- | | Access | Checked at the start | Checked at every entry | | Hours | A working day | Slots, often overnight | | Rules | Yours | The landlord's, plus yours | | Personnel | Stable | Rotates by night | > [!IMPORTANT] > The fourth row breaks manual control. If the authorised personnel list is updated by email, it will always lag behind whoever actually turns up at the service door at ten at night. ## How to organise it 1. **One file per unit or per phase** — With the landlord's rules inside, so nobody hunts for them in an email. 2. **Authorisation per person and per slot** — Who may enter, in which hours, and until when. 3. **A fast lane for the last-minute replacement** — Because it will happen, and the alternative is entry without checks. 4. **And the day's work permit, if the landlord requires it** — Tied to the specific night, not to the project as a whole. > [!WARNING] > What causes friction with landlords is their own rules: noise hours, lift usage, access routes, waste removal. Held inside the file and signed by each company, they stop being an argument and become a checkable requirement. ## What you must be able to show afterwards **En corto** - Who entered each night and under what authorisation. - That they held current training and equipment that day. - That slots and landlord rules were respected. - And the condition it was handed back in each morning, if that is agreed. The last prevents most claims: a photo of the condition at shift end, in the file, closes the conversation about damage that surfaces two days later. > [!NOTE] > It applies equally to industrial maintenance without stopping the line, hospital works and hotel refurbishments floor by floor. The vocabulary and the slot change; the mechanism does not. **What if the landlord has its own access system?** They coexist: theirs controls the door, yours controls whether whoever asks may enter. **How do I handle a replacement at nine at night?** With fast onboarding from a phone; without that route, people will enter unchecked. **Does it suit small one-night jobs?** Yes, and that is where it shows most: there is no time to set anything up by hand. ## Ejemplos **A shopping centre fit-out works at night with personnel changing weekly.** - Authorises per person and slot from the unit's file - Enables fast onboarding for replacements → Nobody enters unchecked and the landlord stops receiving emailed lists that arrive late. **Work happens with the premises open to the public.** - Records the condition of what is not being touched → Other people's damage is not inherited. **The occupier asks for documentation to allow entry.** - Checks per person and per machine beforehand → Access is not discovered blocked. **The working window is short.** - Closes the documentation days in advance → The window is not lost over a paper. **An area is closed and its condition is not recorded.** - Captures the condition at the end of each day → The boundary with what follows is clear. **The occupier complains about something from the last day.** - Checks what was captured that date → The dispute closes by looking. --- --- id: KB-CN-008 url: https://app.codecontract.io/help/construction/architecture-and-engineering-practices idioma: en categoria: sector-construccion subcategoria: arquitectura audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-006, KB-LE-009] citadoPor: [KB-CN-022] --- # Architecture and engineering practices _Deliverables by phase, versions that cross, and liability that lasts years._ **Responde a:** architecture project version control · engineering deliverables by phase · technical project documentation · long-tail professional liability records A practice produces documentation as its product: it does not accumulate it, it delivers it. That changes the problem. What needs controlling is not where a paper is, but which version was delivered, to whom, when, and what was approved from it. ## The three controls that matter | Control | What it prevents | | --- | --- | | Delivered version, with date and recipient | Building from a version that was already superseded | | Client approvals, by phase | A change being treated as accepted when it was not | | A record of requested changes | Scope growing unnoticed and unbilled | > [!IMPORTANT] > The third decides the profitability of the commission. Small changes requested by phone or on site never get billed because nobody noted them, and by project end the practice has done 30% more work than contracted. ## How to organise it without bureaucracy 1. **One file per project, with real phases** — The ones you use and invoice, not a textbook's. 2. **Each delivery recorded as a delivery** — Which version, to whom, when. A minute, and it covers the whole project. 3. **Explicit approval when each phase closes** — Signed, not a "go ahead" on a call. 4. **And change requests noted on receipt** — Even if you decide not to charge: what matters is that they are on record. > [!WARNING] > Professional liability runs for years after delivery. That means the project archive has to outlive changes of system, staff and partners — and leaving it on the machine of whoever drew it is not an option. ## What gets asked for when there is a problem **En corto** - Which version was delivered and what was actually built. - What was warned in writing, and when. - What the client approved and with what documentation in front of them. - And what changes were requested during construction. All four are answered by the same thing: the project file with dated deliveries. And all four are impossible to reconstruct afterwards from three people's inboxes. > [!NOTE] > It applies equally to engineering firms, technical consultancies and design practices: the pattern is "we produce documentation that we deliver", and control is over delivery, not storage. **What about drawings, which are many and large?** Deliver and record the set per phase; there is no need to version each file by hand. **Does it work for collaborations with other practices?** Yes, and there it pays to agree beforehand who keeps the whole. **How long must the project be kept?** Longer than the applicable liability period, with margin. ## Ejemplos **A practice discovers at the end of a project that it did three unbilled rounds of changes.** - Notes each change request on receipt, even when not charging - Records each delivery with version and recipient → The next project closes with the real scope billed and no argument about what was approved. **The design lives on the machine of whoever signs it.** - Stores it off personal machines → One person leaving does not take the archive. **The input data supplied by others disappears.** - Stores what third parties provided with the project → The basis of the calculation still exists. **Several versions circulate and nobody knows which stands.** - Keeps versions with their dates → You can say what applied at each moment. **Something is changed on site and never reaches the practice.** - Records what was communicated and when → Each party's position is documented. **Questions arrive about a project from years ago.** - Keeps the complete file with its date → You answer from the archive. --- --- id: KB-CN-009 url: https://app.codecontract.io/help/construction/public-tenders-preparing-the-documentation idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-015, KB-CN-006] citadoPor: [KB-CS-016] --- # Public tenders: preparing the documentation _What repeats in every bid and what has to be redone each time._ **Responde a:** documentation for public tendering · preparing a public bid · technical capability documentation · what repeats in every tender Bidding for public contracts consumes days of work, and a large part of that work is redoing what was already done for the last one. The difference between a team bidding ten times a year and one bidding thirty is rarely size: it is how much they have prepared in advance. ## What repeats almost every time | Block | How often it changes | What to have | | --- | --- | --- | | Company details and capacity | Rarely | Up to date and ready | | Financial standing | Annually | With the last update date visible | | Similar works completed | When you finish one | With its completion certificate, collected at the end | | Certifications and insurance | Annually | With warnings before they expire | | Assigned technical team | Per bid | With qualifications and experience already digitised | > [!IMPORTANT] > The third row is the most valuable and the worst preserved. The completion certificate is requested when the works finish, while the client relationship is live; requesting it three years later for a specific tender is slow and sometimes impossible. ## How to shorten preparation 1. **A permanent "company documentation" file** — What repeats, always current, not a folder per tender full of copies. 2. **Due dates with warnings** — An expired insurance discovered the evening before submission is the classic cause of exclusion. 3. **One file per tender that links rather than copies** — What is specific to that bid; the common part is referenced. 4. **And collect the certificate as each job ends** — The highest-yield investment and the most forgotten. > [!WARNING] > Beware exclusion on a formality. Many bids fall not on price or technical merit, but because a document had expired, was wrongly signed, or a declaration was missing. It is the most avoidable part and gets the least attention. ## After submitting **En corto** - Keep what was submitted exactly as submitted, with its receipt and date. - And keep losing bids too: next time starts from there. - And note the reason if you were excluded, however painful. That last point reduces future exclusions: the same three mistakes nearly always repeat, and they only become visible once someone has been noting them. > [!NOTE] > It applies equally to large private tenders, supplier approvals and supply competitions: the specification changes, not the fact that 70% of what is asked for is always the same. **Can a previous bid be reused?** The common part yes; the technical content and price, no. **What about joint ventures?** Each company contributes to the shared file; agree beforehand who keeps the whole. **How long must submissions be kept?** Years: appeals and reviews can come much later. ## Ejemplos **A contractor spends four days per tender redoing the same documentation.** - Builds the permanent company file with due dates - Collects the completion certificate as each job ends → Prepares bids in a day and stops losing tenders to expired documents. **The documentation is gathered in the final week.** - Keeps a permanent file current → Each tender costs a fraction of the previous one. **A certificate expires right on the deadline.** - Records expiries with a warning → Renewal happens beforehand. **A document is missing on submission day.** - Checks what is missing in advance → The gap closes with time to spare. **Each tender asks for the same in another format.** - Keeps the original and adapts on submission → The underlying work happens once. **What was submitted must be evidenced after the award.** - Keeps what was submitted, with its date → You answer with what was handed in. --- --- id: KB-CN-010 url: https://app.codecontract.io/help/construction/structural-material-acceptance-on-site idioma: en categoria: sector-construccion subcategoria: estructuras audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-IU-007, KB-CN-006] citadoPor: [KB-CR-017, KB-IU-014] --- # Structural material acceptance on site _What to check when the lorry arrives, because afterwards it is already installed._ **Responde a:** material acceptance control on site · structural steel certificates · supplied concrete documentation · what to check when material arrives on site Structural material has one feature that sets it apart: once it is in place, checking it costs a hundred times more. Anything not looked at during unloading becomes a demolition problem, not a paperwork one. ## What arrives with the material and must be captured | Element | What it evidences | If missing | | --- | --- | --- | | Delivery note identifying the consignment | What arrived and from which heat or batch | Without it, nothing else can be linked to anything | | Product certificate | That the material meets the specification | Request it from the supplier, and it takes time | | Marking and labelling on the material itself | That what is on site is what the paper says | Visible at a glance, if someone looks | | Test results, where applicable | What was checked and with what result | The lab issues them later: they must be chased | > [!IMPORTANT] > The fourth row is the one left pending that nobody chases. Results arrive days after unloading, when the lorry has gone and the works have moved on — and if nobody linked them to the specific consignment, they turn up loose in an inbox and evidence nothing. A test without the consignment it belongs to is a nice-looking piece of paper. ## How to do it without slowing unloading 1. **Photo of the delivery note and the marking, at unloading** — Thirty seconds on a phone, linked to the site and the date. 2. **The consignment as the thread** — Heat, batch or lot: it is what later links material, certificate and test. 3. **Pending tests, recorded as pending** — With who issues them and by when. Unrecorded, they are never chased. 4. **And rejections recorded too** — If something is sent back, that record is worth as much as the accepted material's. > [!WARNING] > The expensive blind spot is material arriving when the responsible person is not there. A seven-in-the-morning or Saturday delivery is received by whoever is present, and without a two-minute route to record it from a phone, nothing remains: no photo, no legible note, no record of who accepted it. That is the gap through which nothing can be reconstructed later. ## What gets asked months or years later **En corto** - Which specific material went into which part of the works. - Its certificate and tests, linked to that consignment. - Who received it and what they checked that day. - And what was done with anything that failed. All four are answered from the site file if they were captured at unloading, and are unreconstructable otherwise. There is no middle ground: either it was caught then or it does not exist. > [!NOTE] > It applies equally to structural steel, supplied concrete, precast elements and structural safety components. The tests and who signs them change; that the filing unit is the consignment, not the order or the invoice, does not. **What if the supplier sends certificates at month end?** That is normal: hence recording them as pending on the day of delivery. **Is it needed on small jobs?** The obligation depends on the project; the cost of doing it is the same and low. **Who should sign for acceptance?** Whoever holds that role on site, and their name should be recorded. ## Ejemplos **A site receives steel on a Saturday and the test results arrive by email two weeks later.** - Photographs the delivery note and marking at unloading, linked to the consignment - Records the tests as pending with an expected date → When the supervising engineer asks, the test is tied to the consignment actually installed. **Material arrives and the delivery note is signed in a rush.** - Captures the note as it is signed → The paper stops being the only copy. **Material arrives without its documentation.** - Puts on record what is missing the same day → The claim goes out while it is easy. **Nobody notes which area each consignment went to.** - Records what was unloaded and where it was used → The data nobody else holds is kept. **At close-out, eight months of delivery documentation is requested.** - Keeps each delivery with its date → The handover is prepared in an afternoon. **A different reference to the one ordered arrives.** - Notes the difference on receipt → The discrepancy is resolved before installation. --- --- id: KB-CN-011 url: https://app.codecontract.io/help/construction/demolition-and-construction-waste idioma: en categoria: sector-construccion subcategoria: demolicion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-005, KB-NO-003] citadoPor: [KB-NO-020] --- # Demolition and construction waste _What gets thrown away is documented too, and some materials mean stopping before you start._ **Responde a:** construction waste documentation · waste management in a demolition · asbestos on site what to do · evidencing where the rubble went On a site, what comes in is documented in detail and what goes out barely at all. And what goes out — rubble, stripped materials, hazardous elements — creates its own obligations, with the peculiarity that by the time someone asks, the material is no longer there to check. ## What you must be able to evidence | Element | What it evidences | When it is produced | | --- | --- | --- | | Pre-demolition survey | What is there and what is expected to come out | Before starting | | Identification of hazardous materials | Whether anything requires special handling | Beforehand, by inspection or testing | | Transfer documents | Where each waste type goes | At every collection | | Waste contractor's certificate | That it arrived and what was done with it | Afterwards, and it must be chased | > [!IMPORTANT] > The fourth row is the one left unclosed. The skip leaves, the works move on, and the contractor's certificate arrives weeks later — or never — when nobody is waiting for it. Without it you have evidence the waste left, but not where it ended up, which is exactly what gets asked. ## What means stopping > [!WARNING] > If a material appears that requires special handling — asbestos is the commonest case in older buildings, but not the only one — **work does not carry on as if nothing had happened**: there are procedures, specifically licensed firms and dedicated documentation that cannot be improvised or backdated. The expensive mistake is not finding it: it is continuing to work while deciding what to do, because from that moment any later record is compromised. ## How to organise it during the works 1. **The survey, in the file rather than a drawer** — It is the reference against which what actually appears is compared. 2. **Each collection, with its document and a photo** — Thirty seconds at the time; unreconstructable later. 3. **Pending certificates, recorded as pending** — With who issues them. Unrecorded, they are never chased. 4. **And the firms involved, with their licences checked** — Especially where materials require them. ## At completion **En corto** - The balance of what was removed against what was expected, with differences explained. - All destination certificates, closed. - And the documentation of everyone involved, valid on the days they worked. That last has a practical consequence: it is not enough that a firm was licensed when you hired them, it must be valid during the days they worked. And that check is yours. > [!NOTE] > Which materials require special handling, which licences are needed and what documentation must be kept and for how long depend on the type of works and the applicable rules, which get updated. **Confirm that with your technical adviser or a specialist before starting**; this only describes what to record so that management is evidenced. **What if the contractor never sends the certificate?** Chase it in writing and keep the chase: it places you far better than silence. **Must waste be separated on site?** It depends on the waste type and your contractor; separating well is usually cheaper even where not required. **Is the haulier's note enough?** As evidence of collection yes; the destination is evidenced by the waste contractor. ## Ejemplos **A company finishes a demolition and months later is asked where the rubble ended up.** - Records destination certificates as pending at each collection - Chases the contractor during the works, not at the end → Closes the file with every destination evidenced instead of with loose delivery notes. **Waste leaves the site and the receipt arrives weeks later.** - Requests and chases automatically → The document arrives without being hunted. **Nobody knows how much has left a project.** - Checks the history per project → The figure comes from the archive. **Receipts are filed by date rather than by project.** - Attaches them to the project that generated them → You search the way people ask. **The contractor changes and the history goes with them.** - Keeps its own copy of every receipt → The change does not take the previous years. **Waste accumulates on site with no date.** - Records the date when it is set aside → Elapsed time is a fact. --- --- id: KB-CN-012 url: https://app.codecontract.io/help/construction/hvac-from-commissioning-to-maintenance idioma: en categoria: sector-construccion subcategoria: climatizacion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-006, KB-CF-014] citadoPor: [KB-CS-037] --- # HVAC: from commissioning to maintenance _The handover between whoever installs and whoever maintains is where the documentation later needed gets lost._ **Responde a:** hvac installation documentation · installation and commissioning certificate · refrigeration maintenance records · f-gas handling documentation An HVAC installation generates documentation at two widely separated moments: when it is fitted and commissioned, and then for years every time someone services it. The problem is that the same company rarely does both, and in that gap exactly what is needed when something fails gets lost. ## What is produced and who holds it | Document | When | Who usually holds it | | --- | --- | --- | | Design or installation specification | Before | The installer or the engineers | | Installation and commissioning certificate | At completion | The installer, and sometimes only them | | Charge and equipment records | At fitting and at each intervention | Whoever handles it, who may be someone else | | Periodic inspections | Throughout its life | Whichever maintainer is current | > [!IMPORTANT] > The second row is the most often lost and the most needed: **the commissioning certificate is issued by the installer, who gets paid and leaves**. If the owner does not claim it at that moment, three years later they will be asking a company they no longer have a relationship with — and that, when the system has a problem or something must be justified, is precisely the worst moment. ## The handover, which is where it fails 1. **Gather the documentation before paying the final application** — It is the only real lever, and it works in HVAC as in any trade. 2. **File it by equipment, not by company** — The installer changes; the machine stays for twenty years. 3. **Give it complete to whoever will maintain it** — A maintainer without the commissioning record works blind and you will notice at the first breakdown. 4. **And add each intervention to the same file** — Even if a different company does it each year. > [!WARNING] > A detail that only surfaces when the maintainer changes: **whoever handles certain equipment and gases needs a specific licence, and that licence belongs to the person or company, not to the equipment**. Checking it is the job of whoever hires, not of whoever turns up in the van. And it must be checked valid on the days they worked, not only on the day the contract was signed. ## What gets asked for later **En corto** - Exactly what was installed and with what characteristics. - The inspections carried out, with dates and by whom. - Interventions on the circuit and what was charged or recovered. - And the licence of whoever did it, valid that day. All four are asked for by an insurer after an incident, by an inspector, or by the next owner. And all four are answered from the equipment's file if they were kept, or not answered at all. > [!NOTE] > Which inspections are mandatory, how often, and which licences are required depend on the installation type, the refrigerant and the applicable rules, which get updated. **Confirm with your engineer or maintainer**; this describes what documentation exists and where it gets lost. **What if the installer no longer exists?** Reconstruct what you can from what is available and note what is missing and why. **Does the maintainer's job sheet count as a record?** Yes, if it goes into the equipment's file the same day and not into an annual folder. **Does this apply to a single unit in an office?** Yes, and it costs less: one file per unit even if there are only two. ## Ejemplos **An owner changes maintainer and the new one asks for the commissioning record, which nobody has.** - On the next project, claims the documentation before the final payment application - Files everything by equipment rather than by company → The next change of maintainer is settled by handing over the equipment's complete file. **Commissioning is documented and then lost.** - Captures the record at the moment → The document reaches the file. **Later maintenance does not know what was installed.** - Stores the file with the installation → Whoever maintains it finds what went in. **Calendar inspections get forgotten.** - Warns about each due date in advance → The calendar keeps itself. **A unit still under warranty is repaired.** - Records which warranties are live → The avoidable cost is avoided. **A client asks you to evidence an old intervention.** - Keeps the history per installation → You answer without reconstructing. --- --- id: KB-CN-013 url: https://app.codecontract.io/help/construction/lifts-and-equipment-inherited-with-the-building idioma: en categoria: sector-construccion subcategoria: ascensores audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-003, KB-CN-006] citadoPor: [KB-LE-017] --- # Lifts and equipment inherited with the building _Installed once, they stay with the building for forty years, changing owner and maintenance firm along the way._ **Responde a:** lift documentation · changing lift maintenance company · lifting equipment inspection · we do not have the lift paperwork A lift, an automatic door or a lifting platform have something unusual about them: they are installed in weeks and then live for decades, with periodic servicing, a maintenance contract and, every so often, an inspection by an outside body. Over that time owners, managers and maintenance firms change — and the documentation falls by the wayside at each handover. ## What is produced and who holds it | Document | Who produces it | Where it usually sits | | --- | --- | --- | | Installation documentation | The installer | With the firm that fitted it, if it still exists | | Equipment registration | Filed at installation | With whoever handled the filing | | Maintenance reports | The current maintainer | In their system, not yours | | Periodic inspection records | The inspecting body | Given to the owner, who sometimes does not keep them | | Repairs and replacements | Whoever carried them out | Spread across several firms over the years | > [!IMPORTANT] > The third row bites when changing provider: **maintenance reports live in the maintainer's system, and on termination they are not always handed over**. The new firm starts its record from zero, and from then on there is no way to show the equipment was maintained through the intervening years. Requesting the full history is part of terminating the contract, not anyone's goodwill, and it must be asked for before signing with the next one. ## How a file per unit is built 1. **One per unit, identified by its number** — It is the only thing that does not change; the site's name does. 2. **With the installation and registration inside** — Even if twenty years old: everything else rests on them. 3. **Reports and inspection records as they arrive** — Every visit leaves paper; filing it then takes a minute. 4. **And inspection due dates warning early** — Arranging an inspection takes weeks, not days. > [!WARNING] > What surprises buyers and tenants: **keeping this current is the owner's responsibility, not the maintenance firm's**. The maintainer does what is contracted and gives notice; whoever answers for a missing inspection or an overdue unit is whoever is registered as the owner. That is why in a sale the equipment documentation is requested before signing, alongside the building's. ## When old paperwork is missing **En corto** - Manufacturers and installers usually keep technical documentation by unit number. - The inspecting body keeps its own records and can issue a copy. - And whatever does not turn up is declared as such: an explained absence is not silence. > [!NOTE] > Which inspections are compulsory, how often and who may carry them out depend on the type of equipment and on the rules of your region and country. **Your maintenance firm or adviser confirms that**; the point here is that what gets produced is not lost at the next handover. **Can I change maintainer without losing the history?** Yes, if you ask before terminating. Afterwards it is far harder. **What if the installer no longer exists?** Search by unit number: the manufacturer and the inspection body usually have a trace. **Does this apply to automatic doors or platforms?** The criterion is the same: unit, file, number and due dates. ## Ejemplos **A building changes maintenance firm and the new one starts with no history.** - Requests the last few years of reports before terminating the previous contract → The unit keeps its full record and inspections stop starting from scratch. **A unit is inherited without its documentation.** - Requests what is missing at contract start → The request happens while there is still a contact. **Mandatory inspections pile up.** - Warns about each due date in advance → The calendar spreads out. **The unit's history sits with the previous maintainer.** - Requests and stores it on taking over → The starting point is known. **An incident repeats and nobody sees the pattern.** - Checks the unit's history → The cause is tackled rather than the symptom. **The contract ends and the history must be handed over.** - Keeps the complete, exportable history → The handover takes hours. --- --- id: KB-CN-014 url: https://app.codecontract.io/help/construction/site-machinery-owned-hired-and-other-peoples idioma: en categoria: sector-construccion subcategoria: maquinariaobra audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-006, KB-CF-014] citadoPor: [KB-CN-018] --- # Site machinery: owned, hired and other people's _Three situations treated as one that are not: who keeps the paperwork and who answers for its use both change._ **Responde a:** site machinery documentation · paperwork for hired plant · the subcontractor brings its own machinery · machinery access control On a mid-sized site, machines from three different sources coexist, and documentation control is usually built for one of them: your own. The other two get improvised, and that is exactly where Monday morning's access problems come from. ## The three situations and what changes | Source | Who holds the paperwork | Who answers for its use | | --- | --- | --- | | Yours | You | You | | Hired | The hire firm issues it; you hold it while it is there | You, while you use it | | A subcontractor's | Their company | Them, but you for letting it in | | Hired with an operator | The supplier, operator's certification included | It is shared, and worth writing down | > [!IMPORTANT] > The second row is the most neglected for one specific reason: **a hired machine's documentation leaves with the machine**. While it is on site you hold it, and the day it goes back it drops out of your reach — but the works carry on, and if in two years someone asks about a job done with it, you will have to show what applied then. A copy goes into the site file on arrival, not on return: by then nobody remembers. ## What to check before it comes in 1. **That the machine's documentation is current** — Inspections, marking and whatever its type requires. 2. **That whoever operates it is certified for that machine** — Certified for one is not certified for all. 3. **The insurance covering it, and how far** — Especially on hire: it does not always include what you assume. 4. **And record the in and out dates** — It is what ties each job to the machine that did it. > [!WARNING] > The case that generates most argument is hire with an operator: **one party supplies the machine and another directs the work**. If it is not written down who gives instructions and who answers for that operator's safety, the answer gets decided after the incident, which is the worst possible moment. Half a signed page at contracting settles what no machine documentation will ever clarify. ## When the subcontractor's machinery arrives **En corto** - Ask of it what you ask of yours, through the same route as their other documents. - The operator is theirs, but they are on your site: certification is checked the same. - And if something comes in undocumented «just for today», record who authorised it. > [!NOTE] > What documentation each type of machine requires, what certification the operator needs and how it is coordinated with the other companies is set by the applicable rules and your prevention service. **Check with them**; here it is about the copy being where it will later be needed. **Should I keep papers for a machine that was there two days?** Yes, with its dates: that is what ties it to those days' work. **Is the hire firm's documentation enough as is?** Yes, keeping a copy while it is there and noting the period. **What if the machine breaks and is swapped?** It is another machine: another number, another set of papers, another date. ## Ejemplos **A contractor returns hired plant and months later is asked for papers on a job it did.** - Files a copy in the site record on arrival, with dates → The job stays tied to the machine that did it, even though the machine is gone. **A hired machine arrives without its documentation.** - Requests it from the hire company before bringing it up → The machine does not sit idle at the bay. **Nobody knows which inspections are due on the owned machine.** - Records expiries per item of plant → The warning arrives before the date. **A subcontractor's machine goes on site unchecked.** - Checks the equipment documentation before authorising → What comes in has been checked. **The equipment documentation sits at the hire company's office.** - Keeps its own copy with the project file → It is shown on site without phoning anyone. **A review asks about a machine from months ago.** - Checks what was recorded on that date → You answer from the record. --- --- id: KB-CN-015 url: https://app.codecontract.io/help/construction/road-maintenance-and-linear-works idioma: en categoria: sector-construccion subcategoria: carreteras audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-005, KB-CS-035] citadoPor: [KB-CN-018] --- # Road maintenance and linear works _The work is not in one place: it is spread over a hundred kilometres, and each job lasts a morning._ **Responde a:** road maintenance job sheets · documenting linear works · controlling scattered jobs · justifying a maintenance contract A maintenance contract is nothing like a building site: there is no compound, no gate, no site manager who sees everything. There are crews that head out in the morning, carry out six jobs in different places and come back — and whatever is written about those six is all that will exist a year from now. ## What is needed from each job | Data | What it is for | When it is captured | | --- | --- | --- | | Exactly where | It is what identifies the job | On site, not back at base | | When, with the time | Orders the sequence and justifies the hours | At the moment | | What was done and with what material | Justifies the certification | Right there | | Before and after photos | What prevents most disputes | Both moments, or neither counts | | Who did it | Closes the sheet | On finishing | > [!IMPORTANT] > The first row is what makes this sector different: **without the exact location, a job cannot be found again**. On a site «third floor» is enough; here «the A-road» is two hundred kilometres with several jobs in similar stretches the same month. When someone claims over a defect at a specific point, the question will be whether you were there and when — and a sheet without a chainage does not answer that, however well written. ## How to capture it without slowing the crew 1. **From a phone and on site, two fields and a photo** — What is written back at base is written wrong. 2. **Location taken from the device itself** — Typing it by hand is where digit errors appear. 3. **One sheet per job, not one per day** — A sheet with six jobs cannot answer for one. 4. **And incidents as separate jobs** — What you found and did not touch counts too. > [!WARNING] > What almost never gets recorded and is later needed: **what was spotted and not fixed**. A crew sees a fallen sign outside their stretch or a defect outside the contract, and moves on. If that is not written down, when there is an accident at that point nobody can show it was spotted, reported and out of scope. Recording it takes thirty seconds and is the difference between having warned and never having been there. ## What whoever contracts you asks for **En corto** - That every certified job can be located on the ground. - That photos tie to a date and a point, not to a folder. - And that the month's data matches what is invoiced, job by job. > [!NOTE] > What documentation each maintenance contract requires, in what format and with what reporting deadlines is set by the tender and the road authority. **The contract itself settles that**; here it is about the data existing at the only moment it can be captured. **What if there is no signal at that point?** The app should store and send later: the data is still taken there. **Do we need photos of everything?** Of anything that could be disputed later, always. That is nearly everything. **How long to keep the sheets?** Longer than the contract: claims arrive later. ## Ejemplos **A maintenance firm receives a claim over a defect at a specific point.** - Captures location, time and photos per job from a phone, on site → It can show when it was there and how it was left, instead of reconstructing by hand. **Work happens in sections and records are written up later.** - Records at the moment, from a phone → The data is exact rather than reconstructed. **The client asks what was done at a specific chainage.** - Records the location alongside the intervention → You answer per point rather than per month. **Job sheets reach the office days later.** - Captures the sheet in the section itself → The month closes on what happened. **An incident is documented and lost among emails.** - Records it in the section's file → The incident lives where people look. **A review asks about work from a year ago.** - Keeps the history per section and date → You answer without reconstructing. --- --- id: KB-CN-016 url: https://app.codecontract.io/help/construction/several-companies-working-at-the-same-site idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-001, KB-CN-005, KB-CN-027] citadoPor: [KB-CN-018] --- # Several companies working at the same site _When three companies share a site, the paperwork stops belonging to each of them and starts belonging to the place._ **Responde a:** coordinating contractors on one site · several subcontractors on the same job · what paperwork to ask a visiting company for · information exchange between concurrent companies A warehouse where an electrician, a cleaning company and a machine manufacturer's technician are all working at once. Each has their own rules, training and insurance, and each knows their job. What none of them knows is what the other two are doing — and that is where things happen. ## What each side owes, and almost nobody delivers in full | Item | The host | The visiting company | | --- | --- | --- | | Site risks | Theirs, in writing | Read them and say whether they are affected | | Risks brought in | Demand them before entry | Those of THEIR work, not generic ones | | Agreed measures | Write them down | Confirm them and pass them to their people | | Who is in charge if something happens | Name them | Know who to call | | Each person's paperwork | Check it on entry | Have it current beforehand, not at the gate | > [!IMPORTANT] > The most repeated failure is not skipping the paperwork: **it is asking once, at company level, and never looking at the people again**. The company delivered its documentation in January, and in July sends two new workers nobody has checked. Because the control happened at company level rather than person level, there are people working on site with nothing on record — and if something happens, that is precisely what gets examined. ## Making it sustainable rather than torture 1. **One request per company, with the list of what is needed** — The same for all, so nobody negotiates their own list. 2. **And inside it, one folder per person** — That is what lets you say «this person may enter» without reviewing everything again. 3. **Expiry dates on whatever expires** — Training, medicals, insurance: nearly all of it expires. 4. **And the gate as the last filter, not the only one** — If the real control happens at the gate, someone will always be arguing with the guard. > [!WARNING] > There is a chain almost nobody walks to the end: **the subcontractor's subcontractor**. You hire A, A brings in B for part of it, and B brings a self-employed worker on a Tuesday. When someone asks who was there that Tuesday, the honest answer is usually that nobody knows. Holding it together does not need a complicated system: it needs the duty to report who enters written into every contract down the chain, and entering unreported to carry a real consequence. ## What to keep afterwards **En corto** - The information exchange with dates: who told whom, and what. - The record of who was on site each day — the first thing asked for after an accident. - The agreed measures and who accepted them. - And the coordination meetings, even ten-minute ones: a meeting without minutes did not happen. > [!NOTE] > Which coordination duties apply, who holds the site, who takes on supervision and exactly what documentation must be exchanged is set by the prevention rules and depends on the relationship between the companies. **Your prevention service settles that**; here we cover the documentary side, which is what collapses under its own weight when nobody organises it. **Is the company handing over its documentation enough?** Not if they then send people who were not in that handover. Useful control is per person. **What about self-employed workers here for a day?** Same criterion. A day is ample time for something to happen. **How long do I keep all this?** Longer than the job lasts. What gets asked after an accident arrives years later. ## Ejemplos **A company handed over its documentation in January and in July sends two new workers.** - Keeps a folder per person as well as per company - Checks on each worker's onboarding, not only the company's → There stop being people on site with nothing on record. **After an incident you are asked who was in the warehouse that Tuesday and nobody knows.** - Logs daily who enters, including self-employed workers and technical visits → The question is answered with a list rather than a reconstruction. **The subcontractor brings in another company for part of the job and does not report it.** - Passes the duty to report who enters down the chain by contract → Entering unreported stops being free and the chain can be walked end to end. **Four firms work at once and nobody sees the whole.** - Checks everyone's status on one screen → The whole is visible without opening four folders. **Each firm says they are ready and one is not.** - Checks per person and per machine → What actually comes in is what gets checked. **Two firms rely on the same subcontractor.** - Records which firms are declared per contract → The overlap surfaces before the day. --- --- id: KB-CN-017 url: https://app.codecontract.io/help/construction/the-developer-who-doesnt-build idioma: en categoria: sector-construccion subcategoria: promocion audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-004, KB-CN-006, KB-CN-028] citadoPor: [KB-CN-022, KB-CN-032] --- # The developer who doesn't build _You lay no bricks and you are the one answering to the buyer. Everything others do ends up in your file._ **Responde a:** documentation a developer must hold · who hands over the building manual · developer liability to the buyer · what paperwork to require from the builder You hire a builder, a design team and half a dozen trades. None of them works for the buyer: **they all work for you, and the buyer knows only you**. That asymmetry sums up the position and explains why a development's file is the hardest on the whole job to complete. ## What ends up in your file even though someone else generates it | What | Generated by | Handed over by | | --- | --- | --- | | Material and equipment certificates | Each trade | **You** | | Installation warranties | Each installer | **You** | | Use and maintenance manuals | The manufacturers | **You** | | As-built documentation | The design team | **You** | > [!IMPORTANT] > **The only moment all of that can be gathered is before the final payment certificate.** Afterwards, the builder has dismantled the site office, the installer is on another development and the manufacturer has changed sales rep. Holding documentation as a condition of final payment is not distrust: it is the only tool you have, and the whole sector understands it because the same is done to all of them. ## What to require by contract, not request at the end 1. **What documentation each party hands over, listed** — Named item by item. «The usual documentation» is not a list. 2. **In what format and when** — With the job running, not on completion. 3. **What share of payment depends on delivering it** — That is what makes it arrive. 4. **And who reviews it before it is accepted** — Receiving a folder is not the same as checking it is complete. > [!WARNING] > The mistake that costs years later: **accepting the documentation without opening it**. A fat folder arrives at handover, gets filed, and nobody checks whether every trade is inside or only three. When a buyer claims about one particular installation, you will find the gap with the builder already settled. Half a day reviewing it on receipt is worth more than any contract clause. > [!NOTE] > What documentation a developer must keep and hand over, what the building manual contains and what statutory warranties apply to the buyer is set by the applicable building rules. **Your adviser or design team settles that**; here we explain how to actually get hold of what must be handed over. **Can I withhold payment over documentation?** If it is in the contract, yes, and it is what makes it arrive. Agree it on signing. **Do I have to give everything to the buyer?** Whatever applies, keeping a copy. Never hand over your only set. **What if something is missing from a trade that no longer exists?** Document what is missing and what you did to get it. That is what holds the position. ## Ejemplos **The handover folder looks complete and three trades are missing from it.** - Reviews the documentation against the list before the final certificate → The gap surfaces while it can still be demanded. **A buyer claims about an installation and the builder has already been wound up.** - Requires each trade's documentation by contract during the works → The file is complete before anyone disappears. **The contract asked for «the usual documentation» and every trade reads it differently.** - Lists each contract's documentary deliverables one by one → What is received matches what was asked for, with no interpretation. **The only set of manuals is handed to the buyer.** - Keeps a copy of everything handed over → The file survives the handover of the home. **A trade closes during the works and their documentation is left half-done.** - Documents what is missing, why, and what was done to obtain it → The gap is explained rather than looking like an oversight. **The documentation arrives on paper and is boxed up in a storeroom.** - Digitises and stores the file where it can be found years later → The claim five years from now is answered without emptying the storeroom. --- --- id: KB-CN-018 url: https://app.codecontract.io/help/construction/the-main-contractor-answering-for-others-work idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-016, KB-CS-001, KB-CN-014, KB-CN-015] citadoPor: [KB-CN-019, KB-CN-020, KB-CN-026] --- # The main contractor answering for others' work _Your name is on the contract and eight companies work on site. Whatever you fail to control is attributed to you anyway._ **Responde a:** subcontractor document control on site · main contractor liability for subcontractors · what paperwork to require from each subcontractor · site access without documentation You are the main contractor: you signed with the client and now eight companies are inside the hoarding, some hired by you and some hired by the ones you hired. To the client —and to anyone who asks— **the site is yours in its entirety**, whoever does the work. ## The three tiers, and where control collapses | Tier | Do you control it | What usually fails | | --- | --- | --- | | Your own staff | Yes | Nothing, apart from expiries | | Direct subcontractors | Nearly always | Staff changes mid-job | | **Your subcontractors' subcontractors** | **Rarely** | **Everyone falls down here** | | One-day self-employed workers | Almost never | And they are the least checked of all | > [!IMPORTANT] > **Control is done per PERSON and per day, not per company and per contract.** A subcontractor delivered their documentation in March and in July sends four new people: on paper everything is in order and on site there are people with nothing on record. If something happens, the first thing examined is who was there that day — and that list either exists or it does not; it is not reconstructed. ## What holds the chain downwards 1. **The duty to report who enters, in every contract** — And travelling downwards: your subcontractor must require it of theirs. 2. **A real consequence for entering unreported** — Without one, the duty is decorative. 3. **The daily record of who was on site** — It is what is always asked for after an incident. 4. **And expiries watched, not checked once** — Training, medicals and insurance lapse during the job. > [!WARNING] > The blind spot that causes most grief: **the worker who comes through the gate with another company**. Someone arrives to take a measurement, a manufacturer's technician adjusts a machine, a driver unloads and stays to help for half an hour. None appears under any subcontractor and all are inside the hoarding. The gate is the only place that shows, and only if whoever controls it knows they count too. > [!NOTE] > What duties a main contractor assumes regarding subcontractors, what documentation must be required and kept, and how site coordination is organised is set by the applicable prevention and subcontracting rules. **Your prevention service settles that**; here we cover the practical control that decides whether that documentation is worth anything. **Am I liable for my subcontractor's subcontractor?** To the client, the site is yours. Hence controlling the chain downwards. **Do I have to check every person?** It is what gets examined after an incident. Per company is not enough. **What about one-day technical visits?** They are inside the hoarding. They count the same. ## Ejemplos **A subcontractor delivered documentation in March and in July sends four new people.** - Controls per person as well as per company, registering on entry → There stop being people on site with nothing on record. **After an incident they ask who was there that day and no record exists.** - Keeps a daily access log, including self-employed workers and visitors → The question is answered with a list rather than a reconstruction. **A subcontractor brings in another company and does not report it.** - Passes the duty to report downwards by contract, with a consequence → The chain can be walked to the last self-employed worker. **A manufacturer's technician comes to adjust a machine and nobody logs it.** - Includes technical visits in the access control → Everyone inside the hoarding is on record. **An operative's training lapses mid-job and nobody notices.** - Watches expiries instead of checking once at the start → The alert fires before it lapses rather than after. **Real control happens at the gate and someone is always arguing with the guard.** - Checks before the first day, leaving the gate as the last filter → Gate arguments disappear because people arrive already checked. --- --- id: KB-CN-019 url: https://app.codecontract.io/help/construction/the-installer-who-arrives-last idioma: en categoria: sector-construccion subcategoria: noresidencial audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-018, KB-CS-017, KB-CN-007] citadoPor: [KB-CN-021, KB-CN-023, KB-CN-029] --- # The installer who arrives last _You arrive with the job finished, in a hurry, and sign over work you never saw done. That is where the risk sits._ **Responde a:** installer certificate liability · signing off an installation i did not do · documentation an installer hands over · asked to certify someone elses work You arrive last, when the job is running late and everyone is in a hurry. Much of what you have to connect is already done: closed ducts, executed penetrations, material installed by someone else. And what you are asked for at the end is a certificate with your name on it. ## What gets signed and what people think gets signed | What people believe | What it usually means | | --- | --- | | «I certify what I installed» | The certificate usually covers the whole installation | | «What came before is not mine» | Connect to it and it becomes yours | | «The design team already checked it» | Their check does not replace yours | | «It is a formality to finish» | It is the document examined if something fails | > [!IMPORTANT] > **What you cannot see, you cannot certify — and saying so in writing is the only thing that protects you.** If the duct was closed before you arrived, record it at the time, with a date: «section X could not be verified as it was already executed and closed». That sentence, written the day it happens, is the difference between certifying with reservations and certifying blind. Written afterwards, it is no longer worth the same. ## What to do on arrival, hurry or no hurry 1. **Photograph what you find, dated** — Especially what you will connect to and did not build. 2. **Ask for documentation of what was executed before** — Material, markings and who installed it. 3. **Record what cannot be verified, at the time** — And put it in writing to whoever hired you. 4. **And hand over your documentation on finishing, not months later** — At handover everyone disappears, you included. > [!WARNING] > The pressure typical of this position and how to hold it: **you will be asked to sign so the job can be handed over, and asked the same day**. A flat refusal breaks the commercial relationship; signing without reservations leaves you alone if something fails. The third way works: certify what you did verify and record, in the same document, what could not be checked and why. It is nearly always accepted, because whoever asks knows exactly what they are asking. > [!NOTE] > What an installation certificate covers, who may issue one and what liability it carries depends on the installation type and the applicable rules. **Your adviser or professional body settles that before you sign**; here we explain how to reach that signature with what you did not see written down rather than remembered. **Can I certify only my part?** It depends on the installation. Ask BEFORE accepting the job, not at signing. **What if the duct was already closed?** Record it at the time and in writing. Later is not the same. **I am being pressed to sign today** Certify what was verified and write down what was not. It is usually accepted. ## Ejemplos **The duct was closed before arrival and the certificate is signed saying nothing.** - Records on the certificate which section could not be verified, and why → The signature covers what was checked, not what nobody saw. **You are asked to sign the same day so the job can be handed over.** - Certifies what was verified and records in writing what remains unchecked → The job is handed over without signing blind or breaking with the client. **Months later a fault appears in a section built by someone else.** - Photographs what is found on arrival, dated → The condition of what was connected to can be evidenced. **Installed material has no documentation and nobody knows who fitted it.** - Requests documentation of prior work before connecting → The installation is certified knowing what it is made of. **Their own documentation is handed over three months after completion.** - Hands over documentation on finishing, before everyone disappears → The project file closes with their part inside it. **A job is accepted without knowing whether only part of it can be certified.** - Asks the certificate's scope before accepting the commission → The scope is known while saying no is still possible. --- --- id: KB-CN-020 url: https://app.codecontract.io/help/construction/the-one-supplying-materials-to-the-site idioma: en categoria: sector-construccion subcategoria: materiales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-018, KB-IU-014] citadoPor: [KB-CN-021, KB-CN-022] --- # The one supplying materials to the site _You deliver a hundred consignments a month to twelve sites. Everyone remembers the lorry; nobody remembers the paperwork until the end._ **Responde a:** documentation accompanying construction materials · asked for certificates on deliveries from months ago · what paperwork goes with each consignment · contractor asking for material documentation Your product reaches the site on a lorry, someone in a hurry unloads it and signs a delivery note. That moment is the only real contact between what you supply and whoever uses it — and **it is also the only moment when that consignment's documentation could have travelled with it at no cost**. It almost never does, which is why the same consignment comes back months later as an urgent request. ## The two lives of a delivery | Moment | What changes hands | What is missing afterwards | | --- | --- | --- | | Unloading | Material and delivery note | Everything else | | The invoice | Amount and reference | The specific consignment | | Weeks later | A phone call | Knowing which batch went to which site | | **End of the project** | **One request for everything** | **Months of deliveries at once** | > [!IMPORTANT] > **What you will be asked for at the end is not «your documentation»: it is the documentation for ONE consignment delivered on ONE date to ONE site.** That difference is everything. A generic product certificate is found in a minute and does not answer the question; what answers it is knowing which batch left on 14 March for the site on such-and-such street. If that was not recorded when the lorry left, it cannot be deduced later. ## What changes the outcome, and happens at delivery 1. **Record which batch goes in each delivery** — One line on the delivery note beats the whole archive at the end. 2. **Attach the document to the delivery, not to the reference** — Same information, different questions answered. 3. **Keep the version current on that day** — Product sheets get updated and today's does not cover March. 4. **Know who on site it was handed to** — Whoever signed for the unloading is rarely whoever asks at the end. > [!WARNING] > The scenario repeated on every project: **the request does not arrive consignment by consignment, it arrives whole and with a deadline**. Someone is closing out the project documentation, discovers eight months of materials missing, and asks for all of it on the same day for Friday. Whoever recorded batches at delivery clears it in an afternoon; whoever did not spends a week reconstructing from delivery notes and memory, and hands over what they can evidence, which is almost never everything. > [!NOTE] > What documentation must accompany each type of construction product, who may require it and what declarations or markings apply **depends on the product and the country, and is settled by your adviser or the relevant body**. Here we cover what decides whether you can hand it over: what gets recorded at delivery and how a specific delivery's paperwork is found months later. **Is the general product certificate not enough?** To trade, yes; to evidence a consignment delivered on a date, no. **Do I have to record batches for everything?** For whatever you will be asked about. And you will be asked about what stays on site. **What if they ask for everything at once at the end?** That is the normal case. It is prepared at delivery, because at the end there is no time. ## Ejemplos **At project close-out, eight months of delivery documentation is requested at once.** - Keeps each document tied to its delivery and date → The handover is prepared in an afternoon rather than a week. **Nobody knows which batch went to which site on 14 March.** - Records batch, date and destination on every delivery → The question about a specific consignment has an answer. **The product sheet is updated and the previous one disappears.** - Stores versions with their dates instead of replacing them → What was delivered can be evidenced with what applied then. **Twelve sites request the same documentation in different formats.** - Serves every request from one file kept current → The work is not redone twelve times. **Whoever signed for the unloading is not whoever chases at the end.** - Records who each consignment was handed to on site → The chase is resolved without reconstructing who was there. **The final request arrives with a deadline and nobody saw it coming.** - Shows what documentation is missing before it is asked for → The gap closes without the site waiting. --- --- id: KB-CN-021 url: https://app.codecontract.io/help/construction/the-one-who-takes-delivery-and-installs-it idioma: en categoria: sector-construccion subcategoria: albanileria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-020, KB-CN-019] citadoPor: [KB-CN-023, KB-CN-024, KB-CN-030] --- # The one who takes delivery and installs it _You sign a delivery note at seven in the morning with the lorry double-parked. That slip is all that will remain of the consignment._ **Responde a:** what to check when taking delivery on site · site delivery notes and material certificates · asked for documentation on material i installed · how to record what was installed where You are the one on site when the lorry arrives, the one who decides whether it gets unloaded and the one who installs it. **Yours is the only position that physically sees the material**, and it is also the one with least time to look at it: there is a lorry waiting, a crew standing idle and an unloading to sort out now. The site's entire documentary system rests on a minute that nobody has. ## What gets decided at unloading without anyone calling it a decision | What happens | What it means | Cost of fixing it later | | --- | --- | --- | | The note is signed | Whatever arrived is accepted | Hard: it is already unloaded | | No documentation arrives | It is installed anyway | High: it must be chased from the supplier | | A different reference arrives | It may serve or it may not | Very high once it is installed | | **Where it went is not recorded** | **Nobody will know later** | **It cannot be reconstructed** | > [!IMPORTANT] > **Recording where each thing was installed is worth more than any certificate, and it is the only thing only you can do.** The supplier can reissue a document; the site manager can ask for it again; nobody can know, six months on, whether those panels went on the north façade or the inner courtyard. That information exists only on the day it is installed, in the head of whoever installed it. ## The minimum, and it fits inside the unloading 1. **A photo of the delivery note as you sign it** — Before it gets wet, lost, or left in the site hut folder. 2. **What was unloaded and which area it is for** — Even one line. It is the data nobody else holds. 3. **If documentation is missing, say so the same day** — By tomorrow the supplier is on another site and another matter. 4. **And keep it somewhere that is not one phone** — The foreman's handset is not the site archive. > [!WARNING] > The real cost of this position is not paid at unloading, it is paid at certification: **when the site demands documentation for what you installed and all you hold are delivery notes**. That starts a negotiation where you are at a disadvantage, because the work is done, part-paid and covered by other trades. What takes thirty seconds on delivery day becomes weeks of email once the material sits behind a wall. > [!NOTE] > What must be checked on receiving materials, what documentation should be required for each delivery and who answers for what is installed **is settled by each project's supervising team and your adviser**, and changes with the type of work. Here we cover the practical part: what to record in the minute available and how not to lose it between the site hut and the office. **Can I refuse to unload if no documentation arrives?** Your contract and the site supervision decide that. What you can always do is put it on record. **Is a photo of the delivery note enough?** It is worth far more than the original, because the original gets lost. **What if the material goes to several areas?** Record the split. That is precisely the case nobody remembers later. ## Ejemplos **The delivery note is signed in a rush and ends up soaked in the site hut.** - Captures the document from a phone at the moment of signing → The paper stops being the only copy. **Six months later nobody knows which material went to which area.** - Records what was unloaded and where it was installed → The question is answered from the record, not from memory. **A consignment arrives with no documentation and is installed anyway.** - Puts on record what is missing the same day → The claim to the supplier goes out while it is still easy. **The site demands documentation for what was installed months ago.** - Keeps each delivery with its date and destination → You answer without negotiating over work already covered up. **Everything is on the foreman's phone and he is off that day.** - Stores what was captured in the project file → The information stops depending on one person. **A different reference to the one ordered arrives and is unloaded anyway.** - Records the discrepancy at the moment of receipt → It is resolved before it is hidden from view. --- --- id: KB-CN-022 url: https://app.codecontract.io/help/construction/the-one-who-must-certify-what-was-installed idioma: en categoria: sector-construccion subcategoria: arquitectura audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-020, KB-CN-017, KB-CN-008] citadoPor: [KB-CN-028, KB-CN-032, KB-CN-034] --- # The one who must certify what was installed _Your signature closes the project and rests on documentation gathered by others, months earlier, without you in mind._ **Responde a:** missing project close-out documentation · gathering certificates from every trade · building handover documentation file · how to keep track of documentation during the works At the end of the project someone has to gather, order and stand behind everything that went into it. That person did not buy the material, did not take delivery of it and did not install it: **they only have to answer for the fact that what went in is what was said would go in**. It is the position with the most responsibility and the least control in the whole chain, and its problem is not technical but one of timing: what should have been collected during the works arrives at the end. ## Why the ending is always the same | What is needed | When it is easy to get | When it is actually asked for | | --- | --- | --- | | Material documentation | The day it arrives | At close-out | | Trade certificates | As each one finishes | Once they have left | | What was installed and where | While it is installed | Months later | | **Changes from what was planned** | **The day they are decided** | **On seeing the result** | > [!IMPORTANT] > **Every week between something happening and its documentation being requested multiplies what it costs to obtain.** That is not an impression, it is the structure of the problem. The trade that finished in March and was paid in April has no incentive in June, and by September the contact may no longer exist. Gathering at the end is not a way of working, it is a commitment to gather at the worst possible moment. ## What turns close-out into a formality 1. **Documentation requested when the event happens** — On receiving the material, on finishing the work — not on closing the file. 2. **A list of what is missing from day one** — If it only appears at the end, it appears complete and all at once. 3. **Each trade seeing their own items** — A list of your own gets dealt with; an email with twenty attachments does not. 4. **And what is delivered being dated** — So you can say when it was known, not only what is known. > [!WARNING] > Signing off with known gaps is the most delicate decision in this position, and it always arrives at the worst moment: a committed handover, a client waiting and a trade that will not answer. **What makes any decision there defensible is not the outcome, it is the trail**: having asked, when, of whom, how many times, and what came back. A gap documented and chased in time is a gap; a gap discovered at the end with no trail looks too much like never having looked. > [!NOTE] > What documentation makes up a project's final handover, who must issue each part and what each party signs **is determined by the applicable rules and each project's engagement, and is settled by your professional body or adviser**. Here we cover the organisational part: how to make it arrive during the works instead of at the end, and how to know at any moment what is missing. **Can documentation be required before certifying each trade?** It is what works best in practice. How it is framed is a contractual matter. **What do I do if something is missing and handover is due?** Put on record what is missing, who was asked and when. The trail is the defence. **Is a shared folder enough?** Storing is half of it. The other half is knowing what is missing without opening it. ## Ejemplos **At close-out, certificates are missing from trades that finished months ago.** - Requests documentation as each trade finishes rather than at the end → It is chased while the trade is still engaged. **The list of what is missing only appears when there is no room left.** - Shows at any moment what is missing and from whom → The gap is visible while it can still be closed. **An email with twenty requests goes out and nobody answers any of them.** - Sends each trade the list of their own items → Each one answers for what is theirs. **Handover is due with a known gap and no way to explain it.** - Keeps what was requested, from whom and how many times → The decision is documented rather than remembered. **Documentation arrives through several channels and nobody knows what exists.** - Gathers everything for the project in one file → The project's status is visible without opening folder after folder. **Chasing the trades takes up the entire final month.** - Chases automatically until the document arrives → The last month goes on reviewing rather than chasing. --- --- id: KB-CN-023 url: https://app.codecontract.io/help/construction/the-one-who-leaves-cable-inside-the-wall idioma: en categoria: sector-construccion subcategoria: electricas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-021, KB-CN-019] citadoPor: [KB-CN-024, KB-CN-025] --- # The one who leaves cable inside the wall _Your work is visible for three days. After that it is behind a wall and exists only if somebody photographed it._ **Responde a:** how to prove what i installed before it was covered · photos of installation before closing the wall · claim about an installation nobody can see · recording what was executed on site You run the line, leave it as it should be and move to the next job. Three days later the drylining crew comes through and **your work disappears for good**. From that moment, anything anyone claims about what is inside that wall —you included— is a claim with nothing behind it, unless somebody recorded something before it was closed. ## The window in which anything can be proved | Moment | What can be seen | Cost of putting it on record | | --- | --- | --- | | While being executed | Everything | Seconds | | Executed and not yet covered | Everything | Seconds | | Covered | Nothing | Opening the wall | | **Under warranty, two years on** | **Nothing** | **Opening it, and arguing who pays** | > [!IMPORTANT] > **What is recorded before covering is not done out of bureaucracy: it is done because it is the last time the work exists visually.** That is the whole difference between a claim closed in a morning and one that starts with a hammer. And it is literally thirty seconds per room, done by the person already standing there, with the phone already in their pocket. ## What is worth recording, and what is not 1. **The run before closing, room by room** — One photo per room with something identifying it. Nothing more is needed. 2. **Whatever departs from the drawing** — It is what nobody can find later and what costs most. 3. **Whatever you found badly done by someone else** — Before you cover it, because afterwards it becomes yours. 4. **And keep it off the phone of whoever took it** — The foreman's camera roll is not the project archive. > [!WARNING] > The case that moves most money in this position is not a failure of yours: **it is someone else's failure attributed to you because yours is the work nobody can see**. Damp appears, or something does not work, and whatever is behind the wall becomes the default suspect. With no record the argument is settled by elimination, and whoever can show nothing loses. With four dated photos, the conversation lasts as long as it takes to look at them. > [!NOTE] > What installation documentation must be issued, who signs it and what checks must be recorded **is determined by the applicable rules and each project's supervising team, and settled by your adviser or professional body**. Here we cover the practical part: how to evidence what was executed in the only moment when it is possible. **Does a phone photo count?** It counts for a great deal, especially if it is dated and stored where it will not be lost. **Do I have to photograph everything?** Whatever is going to be covered, and whatever departed from the drawing. The rest is optional. **What if the fault was someone else's and I covered it?** Which is why it pays to record it before covering, not after being asked. ## Ejemplos **The wall is closed and no record remains of what was installed.** - Allows capturing photos from a phone at the workface → The record is made in the only moment when it is possible. **A problem appears and what cannot be seen is suspected.** - Keeps captures with their date and location → The argument is settled by looking rather than opening. **The photos stay on the phone of whoever took them.** - Stores captures in the project file → The record outlives the change of personnel. **The route departs from the drawing and nobody notes it.** - Records the deviation at the moment of execution → Whoever comes later knows what is really inside. **Someone else's poor work is covered up with no record.** - Records what was found before covering it → Another trade's defect is not inherited by silence. **Under warranty they ask about an installation from two years ago.** - Keeps the record tied to the project and the date → It is answered with what was captured then. --- --- id: KB-CN-024 url: https://app.codecontract.io/help/construction/the-one-who-leaves-pipe-under-the-floor idioma: en categoria: sector-construccion subcategoria: fontaneria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-023, KB-CN-021] citadoPor: [KB-CN-025] --- # The one who leaves pipe under the floor _Yours gets tested once, with nobody watching, and then it is covered in screed. That test is the whole of your defence._ **Responde a:** how to document a pressure test · photos before screeding the installation · leak claim years later · what to record before covering the installation What you install is tested and covered the same day or the next. **The test exists for a few hours and the result, if nobody writes it down, exists only in your head.** And unlike other trades, when yours fails it does not fail discreetly: it turns up months later on the ceiling of the flat below, with the floor already laid and a claim under way. ## What can be proved at each moment | When | What can be shown | With what | | --- | --- | --- | | At the test | That it held | A dated record | | Before covering | What is there and where it runs | Photos by area | | Covered | Nothing | — | | **When the damp appears** | **Only what was recorded** | **The first two** | > [!IMPORTANT] > **Recording the test is not the same as doing it, and in a claim only the first counts.** It is a harsh distinction but it is exactly how it works: an installer who did it and did not record it is, in practical terms, in the same position as one who did not. And since the test is done in an empty building with nobody watching, there are no witnesses worth anything. ## The four records that change a claim 1. **The test result, dated** — And who did it. A photo of the gauge is a perfectly valid record. 2. **The routing before covering** — By area, with something identifying the room. 3. **The singular points** — Joints, penetrations and junctions: that is what gets argued later. 4. **And whatever was outside your scope** — If you connected to something already there, say so at the time. > [!WARNING] > The typical claim does not arrive on the day of the leak: **it arrives after an insurer has commissioned a report and somebody has decided where the water comes from**. By then a section of floor has been lifted, there is a written expert opinion and a version of events formed without you. Arriving at that conversation with a dated test and photographed routing completely changes where the argument starts. > [!NOTE] > What tests must be carried out on each type of installation, how they must be documented and who certifies them **is determined by the applicable rules and the supervising team, and settled by your adviser or professional body**. Here we cover the operational part: how to record the test and the routing without it becoming a task separate from the work. **Does a photo of the gauge count?** It is a perfectly reasonable record, especially if it is dated and stored. **What if an apprentice ran the test?** Record who and when. That is half a question in any expert report. **How long should I keep it?** At least as long as the warranty runs, and your adviser settles that. ## Ejemplos **The test is run and no record of the result remains.** - Allows recording the test with a date from the workface → Having tested is demonstrable rather than remembered. **Months later damp appears and someone is sought to blame.** - Keeps the routing photographed before covering → You contribute something rather than a version of events. **The expert report is written without the installer's input.** - Stores the record with the project and accessible → The contribution arrives in time to count. **The apprentice ran the test and nobody knows who or when.** - Records author and date on every capture → The expert's question has an answer. **Joints and penetrations are not photographed as routine.** - Makes capturing several points in one visit easy → The record covers what actually gets argued. **The claim arrives two years on and there is no file.** - Keeps captures beyond the end of the project → The warranty period is faced with the record from the time. --- --- id: KB-CN-025 url: https://app.codecontract.io/help/construction/the-one-who-covers-everyone-elses-work idioma: en categoria: sector-construccion subcategoria: aislamiento audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-023, KB-CN-024] citadoPor: [KB-CN-029] --- # The one who covers everyone else's work _You do the closing, so somebody else's defect gets buried with your signature on top. What you do not flag beforehand becomes yours._ **Responde a:** blamed for a defect that is not mine · what to check before closing up · putting on record what i find on site · liability for covering another trade's work Yours is the trade that closes: the lining, the suspended ceiling, the insulation, the floor. **You come in last over the work of three or four trades and, when you finish, nothing underneath can ever be seen again.** That casts you, without asking for it, as the last person who could have said something — and in claims that role weighs more than it looks. ## What the closer inherits | What was underneath | Who did it | Who it is attributed to later | | --- | --- | --- | | A correct installation | Another trade | Nobody: there is no problem | | A visible defect | Another trade | **You, for covering it** | | A non-visible defect | Another trade | It gets investigated, expensively | | **An uncommunicated change** | **Another trade** | **Whoever did not record it** | > [!IMPORTANT] > **Closing over a visible defect without saying anything amounts, in practice, to owning it.** Not because a rule says so, but because you were the only one who could see it and did not speak, and that is exactly what gets asked afterwards. Breaking that chain costs two minutes: put on record what you found, dated, before covering it — and carry on working. ## The procedure that protects this position 1. **Look before closing, even if it is not yours** — It is the only inspection that point will ever get. 2. **Record what is visible, without judging it** — A photo and a line. You do not have to say whether it is right or wrong. 3. **Notify whoever it concerns and leave the notice recorded** — The notice is what moves the decision to whoever should take it. 4. **And close when told to, with that stored** — The decision to close is rarely yours; the record is. > [!WARNING] > The mistake in this position is **telling the foreman verbally and carrying on**. It is the natural thing: they are ten metres away, you tell them, they say they will handle it, you close. Months later nobody remembers that conversation, the foreman has left the company, and the only thing on record is that you closed it. A recorded notice does not delay you by a minute and turns «I did warn them» into something you can show. > [!NOTE] > What checks fall to each trade before covering another's work, and how responsibility is shared when a defect surfaces later, **is determined by the contract and the supervising team, and settled by your adviser**. Here we cover the operational part: how to record what was found and the notice given, without slowing the works. **Can I refuse to close?** Your contract and the site supervision decide that. Putting it on record you can always do. **Is telling the foreman enough?** Verbally nothing remains. The same notice, recorded, does. **Is this not distrusting my colleagues?** It is recording what was seen. The alternative is answering for what others did. ## Ejemplos **Closing happens over another trade's defect and months later it is pinned on you.** - Records what was found before covering it → The other trade's defect has a date and a different author. **The notice is given verbally to the foreman and nothing remains.** - Records the notice with recipient and date → «I did warn them» becomes something you can show. **Nobody inspects a point before it disappears.** - Makes capturing easy at the workface without returning to the office → The last possible look leaves a trail. **The foreman who received the notice has left the company.** - Keeps the communication in the project file → The trail outlives the people. **Each trade keeps its own photos separately.** - Gathers the project's records in one place → The sequence of what happened can be reconstructed. **Justification for closing an area is requested two years later.** - Keeps dated records beyond the end of the project → The warranty period is faced with what was captured then. --- --- id: KB-CN-026 url: https://app.codecontract.io/help/construction/working-inside-a-window-of-hours idioma: en categoria: sector-construccion subcategoria: ferrocarriles audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-018, KB-CS-041] citadoPor: [KB-CN-027, KB-CN-028] --- # Working inside a window of hours _You have from one until five in the morning. Anything not settled before you go down gets settled next month._ **Responde a:** night possession works documentation · what must be ready before entering · permit to work and prior authorisations · turned away for missing a document Your work happens inside a closed interval: one night, four hours, a shutdown scheduled months ahead. **The window cannot be extended and cannot be repeated next week** — the next one may be a month away. That turns any documentary problem, however small, into something that costs not an argument but an entire window. ## Where a window is lost | What fails | When it is discovered | What it costs | | --- | --- | --- | | A missing authorisation | On arrival | The whole window | | A missing personal document | At the checkpoint | That person, or the window | | A missing equipment document | When trying to bring it in | The work needing that equipment | | **Something missing from the subcontractor** | **At one in the morning** | **Everything, with no room** | > [!IMPORTANT] > **What makes this position special is not the documentary demand, it is that it allows no correction in flight.** On a normal site, if a paper is missing it gets emailed in the morning and work continues. Here, at one in the morning, there is nobody to call, no office open and no room: whatever is not closed before leaving for the window does not get closed. Which is why the real work in this position happens days earlier. ## The list to close beforehand, not during 1. **Exactly who is going in that night** — By name, not «the usual crew»: the rota changes. 2. **What equipment goes up and what documents it carries** — It is the most forgotten and the most work-blocking. 3. **What is missing, checked with real notice** — Not the day before: with time to obtain it. 4. **And the same for every subcontractor** — Their gap is your gap at the gate. > [!WARNING] > The mistake repeated across every operation of this kind is **checking the documentation on the day**. It is done with good intentions —so it is fresh— and it is exactly when nothing can be fixed any more. The useful check is the one three or four days out, because its purpose is not verifying: it is leaving time to obtain whatever is missing. Checking with no room to act is merely finding out sooner. > [!NOTE] > What authorisations, permits to work and accreditations each infrastructure owner requires, and what training or certification each person needs **is determined by the owner and the applicable rules, and settled by your adviser or prevention service**. Here we cover the organisational part: how to reach the window with everything closed rather than discovering it at the gate. **How far ahead should it be checked?** Far enough to obtain whatever is missing. Never on the day. **What if someone changes at the last minute?** That is the normal case. Which is why it pays to keep more people current than go in. **Equipment too?** Yes, and it is the most forgotten because equipment does not complain. ## Ejemplos **At the checkpoint it turns out a technician's paper is missing.** - Checks per person days in advance → The gap is covered before setting off for the window. **The rota changes and someone unplanned goes in.** - Shows who is current and who is not, per person → The change is resolved by picking someone who can enter. **A machine is left outside over its documentation.** - Stores equipment documentation with the equipment → What goes in is checked the way people are checked. **The subcontractor does not send theirs until the eve.** - Requests and chases with configurable lead time → The request does not depend on someone insisting. **Nobody knows what expires before the next window.** - Warns about expiries with room to act → Renewals are planned around the window. **A whole window is lost over one document.** - Shows the complete status before the appointed day → The check happens while it can still do something. --- --- id: KB-CN-027 url: https://app.codecontract.io/help/construction/coordinating-several-firms-in-one-window idioma: en categoria: sector-construccion subcategoria: puertos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-026, KB-CS-042] citadoPor: [KB-CN-016] --- # Coordinating several firms in one window _Four firms, one window and a sequence that allows no improvisation. If one cannot get in, the other three do not work either._ **Responde a:** coordinating several firms in one shutdown · contractor entry sequence · one firm cannot enter and blocks the rest · documentary control of several contractors at once Your window does not admit one firm: it admits four, in a specific order, because one cannot start until another finishes. **Your job is not to execute, it is to make sure all four can** — which means a documentary problem in any of them, however small, becomes a problem for the whole operation. ## Why the risk does not add, it multiplies | Firms in the window | If each fails 1 time in 20 | Chance of a clean window | | --- | --- | --- | | One | 5% | 95% | | Two | 5% | 90% | | Four | 5% | **81%** | | **Eight** | **5%** | **66%** | > [!IMPORTANT] > **In this position it is not enough for each firm to carry its own: it all has to be seen together and in advance.** Each will tell you they are ready, and each will say so in good faith, because each looks at its own folder. What nobody looks at —and it is exactly what decides the window— is the whole: whether all four are current at once, on the same date, with the specific people going in that night. ## What must be visible at a glance 1. **All four firms on one screen** — If it means opening four folders, it will not be done four times. 2. **Detail per person and per machine** — Company level says nothing about who goes in that night. 3. **What expires between today and the window** — It is the gap that slips through most: at review time it was fine. 4. **And the planned entry sequence** — Because gaps do not cost the same: the first firm's stops everyone. > [!WARNING] > The costliest failure is **discovering at the last moment that two firms relied on the same subcontractor**, and that subcontractor is not current. Each assumed it was covered because «the other one handles it», and nobody checked. In multi-firm operations it pays to look once at the complete list of who will physically be there, without trusting the contractual chart: the window is stopped by whoever is at the gate, not by whoever signed the contract. > [!NOTE] > What coordination duties exist when several firms work in the same place and time, and what falls to the facility owner and to each firm, **is determined by the applicable rules and settled by your prevention service or adviser**. Here we cover the organisational part: how to see the whole before the window rather than firm by firm. **Is each firm not responsible for its own?** It is, and you all still lose the window. Seeing it together is what saves it. **How far ahead do you review?** With enough room for the failing one to fix it. Days, not hours. **And my contractors' subcontractors?** They slip through most. It pays to hold the list of who will physically be there. ## Ejemplos **Four firms say they are ready and one is not.** - Shows the status of all of them at once → The whole is visible without opening four folders. **A document expires between the review and the window.** - Warns about what expires on the appointed date → The gap is caught before it opens. **Two contractors rely on the same subcontractor unknowingly.** - Records which firms are declared under each contract → The overlap surfaces before the night. **Each firm sends documentation in a different format.** - Requests specific documents to a single destination → Comparing stops being manual work. **The review is done at company level and one person fails.** - Allows checking per person and per machine → What actually comes through the gate is what gets checked. **Chasing four firms occupies someone all week.** - Chases automatically until it arrives → The week before goes on preparing rather than nagging. --- --- id: KB-CN-028 url: https://app.codecontract.io/help/construction/signing-that-it-can-reopen idioma: en categoria: sector-construccion subcategoria: aeropuertos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-026, KB-CN-022] citadoPor: [KB-CN-017] --- # Signing that it can reopen _At five in the morning somebody has to say the service can resume. That signature rests on what others did overnight._ **Responde a:** certifying reopening after works · who signs the return to service · what evidence is needed to reopen · checks before resuming service When the window ends, somebody has to say the thing can be used again. **That person has executed nothing**: they have been coordinating, watching and waiting, and now they must sign on the basis of work done by four different firms over four hours, at night, some of it in places that can no longer be seen. It is the signature with the least room and the most consequence in the whole operation. ## What that signature actually rests on | What exists | When it is generated | If it was not generated | | --- | --- | --- | | What was checked at the end | In the window | There is no going back | | What each firm recorded | While executing | You sign on their word | | What was left visible | At the end | It can be looked at again | | **What was covered up** | **Before covering it** | **It no longer exists** | > [!IMPORTANT] > **The decision about what gets recorded during the window cannot be taken by whoever signs at the end: it is taken by the firms while executing, hours earlier.** That lag is the whole problem in this position. At five in the morning you can only sign with what exists, and what exists was decided at two, when nobody was thinking about the signature. Which is why what must be agreed before the window is not only the work: it is what evidence each party leaves. ## What to agree before going in 1. **What checks are made and who makes them** — With names and times, so the sequence can be reconstructed. 2. **What is recorded for each one** — Enough that the signature does not rest on a recollection. 3. **What happens if something cannot be checked** — It is the hard case and must be decided beforehand, not at five. 4. **And how all that reaches whoever signs** — If it is on four different phones, it does not reach them. > [!WARNING] > The situation that defines this position is **signing with a reasonable doubt and no time**. Something is not entirely clear, the firm that did it says it is fine, and in twenty minutes the service must resume. There is no general answer to that —it depends on the risk and the installation— but there is an enormous difference between taking that decision with the record of the work in front of you and taking it blind. The first is a judgement; the second is an act of faith with a signature on it. > [!NOTE] > Who may certify the resumption of a service, what checks are mandatory and what liability that signature carries **is determined by the applicable rules and the facility owner, and settled by your adviser or professional body**. Here we cover the organisational part: how to get the evidence of what was executed to whoever must sign, inside the window. **Can I sign relying on what I am told?** It is what happens in practice; with the record in front of you it becomes an informed judgement. **What if something could not be checked?** Put it on record. A documented limit protects far more than silence. **How does the evidence arrive in time?** By capturing it on the spot, not transcribing it afterwards. ## Ejemplos **At five the signature is due and the evidence is on four phones.** - Gathers what everyone captured into one file → Whoever signs sees the work rather than hearing about it. **A check could not be made and nothing is on record.** - Allows recording the limitation alongside the rest → The doubt is documented rather than forgotten. **It is unclear who made each check and at what time.** - Records author and time on every capture → The night's sequence can be reconstructed. **What was covered during the window was not recorded.** - Makes capturing easy at the workface before covering → What disappears leaves a trail. **The next day questions arrive and four firms have to be called.** - Keeps the window's complete file → It is answered from what is stored. **Evidence is transcribed in the morning and loses detail.** - Records at the moment and on the spot → What is stored is what was seen. --- --- id: KB-CN-029 url: https://app.codecontract.io/help/construction/the-one-who-installs-what-the-street-sees idioma: en categoria: sector-construccion subcategoria: fachadas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-019, KB-CN-025] citadoPor: [KB-CN-030, KB-CN-031] --- # The one who installs what the street sees _Your work is judged from the pavement, without a ladder and without context. A defect of yours is not discovered: it is seen._ **Responde a:** claims over visible facade defects · how to document the condition at completion · blamed for something that was already like that · shade variation between material batches Yours does not need looking for: it is on the street, in plain view, every day. **A defect in your work does not appear in a review, it appears in a photo somebody sends round a group chat** — and that completely changes the kind of argument you will have, because nobody argues whether it exists, they argue whose it is. ## The three arguments that always arrive | The argument | What it depends on | What closes it | | --- | --- | --- | | «This is badly fitted» | The execution | The record of how it was executed | | «This is not the same shade» | **The material, not you** | The consignment and its documentation | | «This is damaged» | Who came through afterwards | The condition at completion, dated | | **«This is not what I asked for»** | **The design** | **What was approved, and by whom** | > [!IMPORTANT] > **Two of the four arguments are not about your work, and you have them anyway.** Shade variation between consignments belongs to the material and you have known since it arrived; later damage was done by another trade or by use. The only thing separating «a problem we answer for» from «a problem attributed to us» is having recorded the consignment on arrival and the condition at completion. Both cost minutes and neither happens unless decided beforehand. ## The three moments to record 1. **Receipt of the material, by consignment** — Especially where there are shades, batches or runs: it is the commonest argument. 2. **What was approved before executing** — Samples, colours, setting-out: with who approved and when. 3. **The condition when your work finishes** — It is your boundary with everything that happens afterwards. 4. **And what you found of the substrate** — If what is underneath was not right, say so before covering it. > [!WARNING] > The completion photo is the most profitable of all and almost nobody takes it: **the day you finish, your work is in its best condition and from then on it can only get worse through causes not yours**. Other trades come through, there is a move-in, a year passes. When the claim arrives, the only way to separate yours from what came later is a dated photo from that day. Without it, any mark is arguable — and arguable ones end up repaired. > [!NOTE] > What warranties cover each element, what counts as a defect and what tolerances are acceptable **is determined by the design, the applicable rules and the contract, and settled by your adviser or the supervising team**. Here we cover the organisational part: how to evidence the consignment, the approval and the condition at completion. **Is shade variation a defect?** It depends on the material and what was agreed. What protects you is having the consignment on record. **Must I photograph the whole facade?** Enough to locate each area. It does not need to be a photo shoot. **What if another trade caused the damage?** With the completion photo it is a ten-minute conversation; without it, it is not. ## Ejemplos **Damage appears and is pinned on whoever worked there last.** - Keeps the condition recorded at completion, dated → The boundary with what came later is demonstrable. **A shade difference between areas is disputed.** - Keeps documentation for each consignment received → The origin is located without arguing over workmanship. **Nobody remembers which sample was approved or by whom.** - Records what was approved with author and date → The agreed expectation is fixed. **The completion photos stay on the team leader's phone.** - Stores captures in the project file → The record outlives the people. **The substrate arrived poor and work went on over it in silence.** - Records what was found before executing → Another trade's defect is not inherited by silence. **The claim arrives two years after completion.** - Keeps the file beyond the end of the project → The warranty period is faced with the record from then. --- --- id: KB-CN-030 url: https://app.codecontract.io/help/construction/making-to-measure-from-site-dimensions idioma: en categoria: sector-construccion subcategoria: carpinteria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-029, KB-CN-021] citadoPor: [KB-CN-031] --- # Making to measure from site dimensions _You measure a site that is still moving and manufacture to that figure. If the site changed, the piece is scrap and the argument is who measured._ **Responde a:** who answers if the site dimension was wrong · documenting site measurements · the piece does not fit whose fault is it · confirming dimensions before manufacturing Your product does not exist until somebody goes to site and measures. From that figure material is cut, a piece is manufactured and something is transported that **fits that opening and no other**. If the figure was wrong, or stopped being right between measuring and delivery, there is no adjustment possible: there is a useless piece, a lost deadline and a conversation about who measured. ## Everything that can happen between measuring and fitting | What happens | How often | Who knows | | --- | --- | --- | | The site changes the opening | Common | Whoever changed it, sometimes nobody else | | Measured before a finish goes on | Common | Whoever measured, if they noted it | | The design changes | It happens | It should be communicated, sometimes it is not | | **The figure was transcribed wrong** | **It happens** | **Nobody, until fitting day** | > [!IMPORTANT] > **A site dimension is a snapshot of a moment, not a permanent fact — and this whole position consists of treating it as what it is.** Recording when it was measured, what state the opening was in and what was assumed (that it would be finished, that the floor would rise two centimetres) turns an unresolvable argument into a comparison between two states. Without that, when the piece does not fit there are only two accounts and no referee. ## What turns a measurement into a document 1. **Date and state of the opening when measured** — A photo of the opening with the figure is the complete record. 2. **What was assumed still to come** — It is where half the mismatches are born. 3. **Confirmation from whoever runs the site** — Before cutting. Afterwards it is a claim, not a confirmation. 4. **And notice if anything changed later** — Changes reaching you is not automatic: it has to be asked for. > [!WARNING] > The costliest point in this position is **the time between confirming and fitting**, which on a site is weeks. During those weeks the opening is still alive: someone raises a floor, changes a frame, adjusts a partition. Nobody tells you because to them it is a minor adjustment, and to you it is a manufactured piece. Asking explicitly that any change to those openings be communicated is not over-caution: it is the only warning that can arrive in time. > [!NOTE] > Who answers for site dimensions, what counts as an order modification and how the cost of a useless piece is shared **is determined by the contract, and settled by your adviser**. Here we cover the operational part: how to record the measurement and its context so the conversation has something to resolve on. **Does a photo with the figure count?** It is among the most useful records there are, especially showing the opening's state. **Should I ask for written confirmation?** It is what turns an assumption of yours into a decision by the site. **What if they change the opening after confirmation?** That is the case to agree beforehand: being told does not happen by itself. ## Ejemplos **The piece does not fit and there are two accounts of the dimension.** - Keeps the measurement with its date and a photo of the opening → Comparison replaces argument. **It was measured before a finish went on and nobody noted it.** - Allows recording assumptions alongside the figure → The mismatch is explained rather than attributed. **The site changes the opening after the order is confirmed.** - Records the confirmation with date and author → The change can be placed after the agreement. **Figures are transcribed from paper to the order and one is wrong.** - Captures the measurement at source without transcription → The step where errors creep in disappears. **Each fitter keeps their measurement notes separately.** - Gathers measurements in the project file → Anyone can consult what was measured. **Nobody gives notice of a change to an already confirmed opening.** - Records what was asked to be communicated and to whom → The request for notice is demonstrable. --- --- id: KB-CN-031 url: https://app.codecontract.io/help/construction/the-one-who-finishes-and-inherits-everyone-elses-knocks idioma: en categoria: sector-construccion subcategoria: acabados audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-029, KB-CN-030] citadoPor: [KB-CN-032] --- # The one who finishes and inherits everyone else's knocks _You come in last, over everyone's mess, and whatever is unresolved on inspection day will be yours._ **Responde a:** snagging list at project end · blamed for knocks i did not cause · how to document the condition before finishing · managing snagging with the client You arrive once everyone else has finished, and the space you work in is the accumulated result of months of people passing through with materials, tools and haste. **Your job consists literally of making none of that show** — and for that reason, anything still showing on inspection day reads as yours, whether you caused it or not. ## Where each snagging item comes from | The item | Who caused it | Who repairs it in practice | | --- | --- | --- | | A poor finish | You | You | | A knock from another trade | Someone else | **You** | | Damage from the move-in | The client themselves | It gets argued | | **A different expectation** | **Nobody** | **It gets argued a lot** | > [!IMPORTANT] > **The only real defence in this position is the starting condition, and it must be captured before you begin, not when the list appears.** It is counter-intuitive because the instinct is to start straight away: the area is finally free, there is pressure, and documenting looks like lost time. But it is the only moment when what you found can be distinguished from what you are about to do, and without that distinction everything visible at the end is yours by default. ## How to run snagging without losing it 1. **Capture the condition before entering the area** — Quickly and by area. It is the starting line. 2. **Record damage that appears while you work** — Because it keeps appearing: others are still passing through. 3. **Run the list with status, not on a sheet** — Snagging lives for weeks and changes every day. 4. **And close each item with evidence** — Anything repaired without a photo reappears on the next list. > [!WARNING] > What makes snagging unbearable is not the number of items: **it is that the list has no status and every visit reopens all of it**. Something is repaired, it is looked at again, somebody notes the same thing again because there is no record it was fixed, and a thirty-item list becomes three visits of thirty items. Closing each item with a photo and a date stops that dead, and it is the difference between finishing a project and never quite finishing it. > [!NOTE] > What counts as a finishing defect, what tolerances are acceptable and who is responsible for repairing each item **is determined by the design, the contract and the supervising team, and settled by your adviser**. Here we cover the operational part: how to capture the starting point and run snagging with status until it closes. **Is photographing before starting worth it?** It is the only thing separating what you found from what you did. **How do I avoid repairing other people's damage?** The starting condition does not always avoid it, but it lets you discuss it. **What if the list never closes?** Usually because it has no status. Close each item with evidence and a date. ## Ejemplos **Knocks from other trades are pinned on the finishing trade.** - Captures the condition of the area before starting → What was found is distinguished from what was done. **The snagging list lives on a sheet and reopens at every visit.** - Runs each item with its status until closed → The list goes down instead of repeating. **An item is repaired and noted again at the next visit.** - Closes each item with evidence and a date → What was repaired stops returning to the list. **New damage appears while working and nobody records it.** - Allows adding incidents at the moment → What happens during is kept separate from yours. **The client and the site run different lists.** - Maintains one shared list → Everyone argues about the same thing. **Closing the project drags on for months over snagging.** - Shows what is outstanding and whose it is → Close-out advances on data rather than on visits. --- --- id: KB-CN-032 url: https://app.codecontract.io/help/construction/answering-to-a-hundred-buyers idioma: en categoria: sector-construccion subcategoria: residencial audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-017, KB-CN-022, KB-CN-031] citadoPor: [KB-CN-033] --- # Answering to a hundred buyers _The project ended and a hundred new relationships began, each with its own file, its own warranty and its own way of writing._ **Responde a:** documentation to hand over to the buyer · managing warranty issues on a development · each owner claiming separately · what to keep after handing over homes On handover day your work does not end: **it changes shape**. Until then you had a project, a contractor and a supervising team; from there you have a hundred private clients who do not know each other, who write through different channels and who will ask you things for years. It is a completely different documentary problem from building, and almost nobody prepares for it before needing to. ## What changes on handover day | What changes | During the works | After handover | | --- | --- | --- | | How many people you deal with | A few | A hundred, separately | | What they ask about | The project | Their home | | How long it lasts | Months | Years | | **What is needed to answer** | **The project file** | **Each unit's file** | > [!IMPORTANT] > **The file you need afterwards is not the project's, it is each home's — and it can only be built while building.** That is the structural error in this position. Everything archived during the works is organised by work packages, contractors and phases, which is how it is executed. But every question that arrives later starts with «in my flat...», and translating from one organisation to the other after the fact is work nobody is going to do. ## What to set up before handing over 1. **What each buyer receives, on record** — With acknowledgement: half the complaints start with «nobody gave me that». 2. **One place for them to raise issues** — Without it they arrive by phone, by email and by text. 3. **Which contractor answers for what** — You know; the buyer has no reason to. 4. **And the trail of each issue** — Because the same one will reopen a year from now. > [!WARNING] > The issue repeated on every development is **the one affecting several homes and arriving one at a time**. Four owners report the same thing over four weeks, each is dealt with separately, and nobody sees the pattern until the fifth. Handled together there is one cause, one contractor and one repair; handled separately there are four visits, four conversations and four versions of the answer that later contradict each other between neighbours. > [!NOTE] > What documentation must be handed to the buyer, what warranties cover what and for how long, and what retention duties you carry **is determined by the applicable rules and the contract, and settled by your adviser**. Here we cover the organisational part: how to have the per-home file built before handover and how to run issues without losing them. **Must I keep everything from the works after handover?** At least whatever answers questions about each home, for the period your adviser sets. **How do I stop everyone writing wherever they like?** By giving one clear place from day one. Afterwards is too late. **What if the same issue appears in several homes?** That is the normal case. Seeing it together saves half the work. ## Ejemplos **An owner says they never received their documentation.** - Keeps what was handed to each one and when → Handover is demonstrable rather than remembered. **Issues arrive by phone, email and messaging.** - Offers one place to report them → Everything stays in one thread and nothing is lost. **The same issue appears in four homes separately.** - Shows issues together and by development → The pattern is visible before the fourth visit. **The file is organised by work package and questions come per home.** - Allows organising documentation by unit → You answer in the terms the question is asked. **Nobody remembers which contractor answered for a package.** - Stores which firm executed what, with the file → The issue goes straight to whoever resolves it. **A complaint reopens a year later.** - Keeps the trail of what was done on each issue → You answer with what was done at the time. --- --- id: KB-CN-033 url: https://app.codecontract.io/help/construction/maintaining-what-somebody-else-built idioma: en categoria: sector-construccion subcategoria: mantenimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-032, KB-CS-042] citadoPor: [KB-CN-035] --- # Maintaining what somebody else built _You are handed the keys to a building and an incomplete folder. Whatever is not in it you will discover by opening things._ **Responde a:** taking over maintenance of an existing building · no documentation for the installations · what to request when starting a maintenance contract · asset inventory for a building You start a contract on a building you did not construct, with installations you did not choose and documentation handed over by somebody who was not there either when it was built. **What you receive on day one is all you are going to receive**: from then on, everything missing is discovered at the most expensive possible moment, which is when something has broken. ## What is inherited and what is not | What exists | What is usually received | What is needed | | --- | --- | --- | | The building | The keys | Knowing what is inside | | The installations | A folder | Makes, models and locations | | The history | Almost never | What has been done before | | **Live warranties** | **Rarely** | **What NOT to touch yet** | > [!IMPORTANT] > **The single fact that saves most money and is almost never handed over is what is still under warranty.** A unit you repair that was covered is money lost twice: what the repair cost and what not repairing it would have cost. Asking at the start costs one conversation; discovering it after the first breakdown costs the whole breakdown and is not recoverable. ## What to establish in the first weeks 1. **Your own inventory, even a basic one** — What exists, where it is and what make. Without it nothing can be planned. 2. **Which inspections fall due and when** — Calendar-driven ones give no warning and arrive all together. 3. **What documentation is missing, listed and requested** — At the start there is a contact; in six months there may not be. 4. **And where what you generate will be kept** — Your history starts today and it is the contract's asset. > [!WARNING] > There is a predictable ending worth bearing in mind from the start: **one day this contract ends and somebody will ask for the history**. If everything you have done over five years lives in paper job sheets and in the heads of two technicians, that handover will be exactly as bad as the one you suffered — and it also leaves you with no case for renewal, because you cannot show what you did. A well-kept history is what defends you in both directions. > [!NOTE] > Which inspections are mandatory for each installation, at what intervals, who may carry them out and what records must be kept **is determined by the rules applying to each item of plant, and settled by your adviser or the competent body**. Here we cover the organisational part: how to establish the inventory and the calendar when a building is inherited blind. **What do I ask for on day one?** Inventory, live warranties and history. In that order, in writing. **What if no documentation exists?** You build it. It is a start-up cost, recovered on the first breakdown avoided. **Is keeping my own history worth it?** It is what defends you in a claim and in a renewal. ## Ejemplos **A unit still under warranty is repaired at your cost.** - Records which warranties are live and until when → The avoidable cost is avoided. **Nobody knows what installations exist or where they are.** - Allows building and consulting the inventory → Maintenance is planned on data. **Calendar inspections all fall due at once.** - Warns about each due date in advance → The calendar spreads out instead of bunching. **The history lives on paper job sheets and in two technicians.** - Stores each intervention in the building's file → Knowledge stops being personal. **Documentation is missing and there is nobody left to ask.** - Records what was requested at contract start → The request happens while there is still a contact. **The contract ends and five years of work must be handed over.** - Keeps the complete, exportable history → The handover takes hours and evidences the work done. --- --- id: KB-CN-034 url: https://app.codecontract.io/help/construction/the-designer-questioned-years-later idioma: en categoria: sector-construccion subcategoria: ingenieriacivil audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-022, KB-IU-022] citadoPor: [KB-CN-035] --- # The designer questioned years later _That was calculated eight years ago on certain data and certain criteria. Today somebody asks about it, and only what you filed exists._ **Responde a:** how long to keep project calculations · asked about a project from years ago · which version of the design was built · design documentation and site changes You signed a design, it was built, and years passed. Today a question arrives: an extension, a change of use, an incident, a review. **Whoever asks does not want to know whether you worked well: they want to know on what data and on what criteria that was decided**, and the answer is not in the design you delivered but in what sits behind it. ## What gets asked and where the answer lives | The question | Where the answer lives | If it was not archived | | --- | --- | --- | | What was designed? | In the delivered design | It usually exists | | On what input data? | In the annexes and studies | **It is lost first** | | What criteria were applied? | In the calculation, not the drawing | It cannot be deduced | | **What was actually built?** | **In the site changes** | **It rarely returns to the designer** | > [!IMPORTANT] > **What is lost first is not the design: it is the input data.** The delivered design survives because copies sit in several places. What disappears is the ground investigation they gave you, the flow figures you were handed, the assumption confirmed by email — everything that reached you from outside and on which the calculation rests. And it is exactly what is needed, years later, to explain why what was decided was decided. ## What to archive with ten years in mind 1. **The input data and who supplied it** — With dates. The calculation rests on it, and it was not yours. 2. **The criteria and rules applied** — With their version: they change, and what applied then applied. 3. **What was modified during construction** — It is what separates you from what was actually built. 4. **And which version is definitive** — With several circulating, the question will always be which. > [!WARNING] > The specific risk in this position is **being asked about something built differently from how you designed it**. It happens often, almost always for sound reasons taken on site, and it does not always come back to the designer. Years later the question reaches whoever signed, not whoever decided the change. Having on file what was modified, who decided it and when you were told —or that you were not— is the difference between explaining and carrying it. > [!NOTE] > For how long project documentation must be retained, what liability reaches the designer and over what periods **is determined by the applicable rules, and settled by your professional body or adviser**. Here we cover the organisational part: what to archive in order to explain a technical decision a decade later. **How long must it be kept?** Longer than the project lasts, and your adviser settles the exact period. **Should I keep data that others gave me?** Especially that. It is the basis of the calculation and it is not yours. **What if it was built differently from the design?** Archive what changed and what you were told. That is what places you. ## Ejemplos **Questions arrive about a project from eight years ago.** - Keeps the complete file with its date → It is answered from the archive, not from memory. **The input data supplied by others can no longer be found.** - Stores what was received from third parties with the project → The basis of the calculation still exists. **Several versions circulate and nobody knows which was built.** - Keeps versions with dates instead of replacing them → You can say what applied at each moment. **Something was changed on site and never reached the designer.** - Records what was communicated and when → Each party's position is documented. **The file lives on the computer of whoever signed it.** - Stores projects outside personal machines → One person leaving does not take the archive. **Documentation must go to a third party without over-disclosing.** - Controls which documents are shared and with whom → What was asked for is handed over, not what sat beside it. --- --- id: KB-CN-035 url: https://app.codecontract.io/help/construction/measuring-every-day-that-nobody-looks-at idioma: en categoria: sector-construccion subcategoria: hidraulicas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CN-033, KB-IU-013, KB-CN-034] citadoPor: [KB-IU-026] --- # Measuring every day that nobody looks at _Your installation generates data continuously and most of it nobody reads. The day it is requested, it is worth exactly what was retained._ **Responde a:** how long to keep operating records · continuous measurement data and its evidence · asked for readings from two years ago · what to do with the records the installation generates An operating installation produces records continuously: flows, levels, readings, operating logs, incidents. **The vast majority are never read by anyone**, and that is precisely why they are managed badly: it is hard to look after something nobody uses. Until a specific request arrives about a specific day, and then the whole value of the system concentrates on whether that day was kept or not. ## The life cycle of a record nobody reads | Moment | Who uses it | What usually happens to it | | --- | --- | --- | | The day it is generated | The operator | A quick glance | | The following week | Nobody | Filed, or not | | The following year | Nobody | Lost in a system change | | **The day it is requested** | **Everyone** | **It gets hunted for** | > [!IMPORTANT] > **A record nobody ever uses still has a perfectly calculable value: that of the day it is requested.** It is the whole argument in this position, and it needs stating explicitly because intuition says the opposite. The cost of keeping is small, constant and visible; the cost of not having is enormous, occasional and invisible until it happens. Systems designed looking only at the first always end up in the second. ## What to decide once 1. **What is kept and for how long** — Decided, not inherited from the previous system by inertia. 2. **Where it lives, and not on a local machine** — System changes are where histories disappear. 3. **What happens to anomalies** — An odd reading with no explanation beside it is worse than no reading. 4. **And who can consult it without asking permission** — If someone has to be phoned, in practice it does not exist. > [!WARNING] > The moment these archives are lost is not a deletion: **it is a migration**. The control system changes, the supplier changes, the server changes, and the previous history «stays there for now» — until that machine is retired. Nobody decides to lose it and nobody notices it is gone, because by then nobody was consulting it. Any system change should explicitly cover what happens to the old data, and almost none do. > [!NOTE] > What operating records are mandatory for your installation, at what frequency, for how long they must be retained and who may require them **is determined by the applicable rules and your authorisation, and settled by your adviser or the competent body**. Here we cover the organisational part: how to retain and find records nobody consults until the day they are needed. **Is keeping what nobody reads worth it?** It is worth exactly what not having it will cost the day it is asked for. **What do I do with an anomalous reading?** Keep it with its explanation beside it. Deleting is the worst option. **And when changing systems?** Decide explicitly what happens to the history. That is when it is lost. ## Ejemplos **Readings from a specific day two years ago are requested.** - Keeps records dated and accessible → It is answered by searching rather than reconstructing. **A system change leaves the history on a retired machine.** - Stores records off local machines → The migration does not take the previous years with it. **An anomalous reading appears with no explanation.** - Allows noting the context alongside the record → The anomaly is explained rather than raising suspicion. **Consulting the history means phoning whoever manages it.** - Keeps the archive available to whoever needs it → The query does not depend on one person. **Nobody knows what must be kept or for how long.** - Applies a uniform retention policy → The decision is taken once and applies itself. **Operating logs stay on paper at the installation.** - Captures the log on site and stores it at once → The record stops living in a physical folder. --- --- id: KB-CS-006 url: https://app.codecontract.io/help/construction/site-access-control-by-paperwork idioma: en categoria: sector-construccion subcategoria: obracivil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-002, KB-CF-002] citadoPor: [KB-CS-015, KB-CS-016, KB-CS-017, KB-CN-001, KB-CS-029, KB-IU-005, KB-CN-005, KB-CN-007, KB-CS-039, KB-CN-014] --- # Keeping unqualified people off site _Tie site access to paperwork, and let the system keep count._ **Responde a:** site access control documentation · contractor safety coordination · worker without training on site · construction subcontractor paperwork On site the problem is not having the paperwork: it is that the person on the scaffold today is one of the people who have it. Between those two things sits a list somebody updates by hand, and that is where it breaks. **En corto** - Status is calculated per person, not per company. - Lapsed training removes that person from the list without anyone checking. - The site manager checks from a phone, at the gate. ## How to set it up 1. **One case per subcontractor, with their workers as participants.** 2. **Company documents in one phase; each person's in their own.** 3. **Whatever expires — training, medicals, insurance — marked as such.** 4. **The site manager checks the cleared list before opening the gate.** > [!IMPORTANT] > Someone entering without current training is not an administrative breach: it is the person who gets hurt and the liability that follows. This is the case where the list has to be genuinely right. ## What changes versus a spreadsheet | With a spreadsheet | With a case | | --- | --- | | Somebody updates the list | Status recalculates itself | | Expiries are checked when someone remembers | They warn before lapsing | | The site manager phones the office | Checks it on a phone | | At an inspection, you search | You show | > [!NOTE] > Setting training to warn 60 days out leaves time to arrange a course. Fifteen does not, and the person stays off site until they have done it. **What about self-employed contractors?** The same: a participant with their own documents. **Does it serve for contractor safety coordination?** It is exactly the file you have to produce for it. **Can I give the safety coordinator access?** Yes, read-only and scoped to that site. ## Ejemplos **A site with nine subcontractors and a hundred and twenty workers tracks it in a spreadsheet.** - Moves each subcontractor to a case with their workers - Marks training and medicals as expiring → The site manager checks at the gate, and the next inspection finds no worker without current paperwork. **Entry is authorised by looking at an out-of-date folder.** - Checks the status in the moment → The decision uses today's data. **Somebody not on the list comes in.** - Checks per person before authorising → What comes through the gate is what was checked. **The authorised list is on paper in the site hut.** - Checks it from a phone at the gate → The control works where the gate is. **A document expires and nobody withdraws the authorisation.** - Lets the expiry withdraw it → Access reflects the real situation. **The client asks who came in on a specific day.** - Checks the record of authorised access → You answer using that day's date. --- --- id: KB-CS-020 url: https://app.codecontract.io/help/logistics/warehousing-and-last-mile idioma: en categoria: sector-logistica subcategoria: terrestre audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-008, KB-NO-003] citadoPor: [KB-LG-001, KB-CS-028, KB-LG-002, KB-LG-003, KB-LG-006, KB-LG-016] --- # Warehousing and last mile _Deliveries that need proving and couriers who change every week._ **Responde a:** signed proof of delivery · subcontracted courier documentation · digital delivery note signed · damaged goods claim In last-mile delivery two things get disputed: whether it was delivered and in what condition. Both are settled at the moment of delivery or not at all, because afterwards it is the courier's word against the customer's. ## The three modules | What | Module | When | | --- | --- | --- | | Onboarding the courier or subcontracted firm | Trackline | Before they deliver, with expiries | | Proof of delivery signed by the recipient | Consigne | On every delivery, from a phone | | Condition of the goods on delivery | SmartCheck | Certified photos when there is an incident | > [!IMPORTANT] > A photo of damaged goods only counts if it is dated by a third party. It is what separates a claim closed in a day from one that ends up split between carrier, warehouse and customer. ## Frameworks cited Road transport regulation and its authorisations, the transport contract and its accompanying documents, driving and rest times, and — for dangerous goods — specific transport rules. Which documents accompany each shipment depends on the goods and the destination; confirm with your adviser. > [!WARNING] > With subcontracted couriers who change often, checking has to be per person and at loading time. A list from the subcontractor does not say who is in the van today. > [!NOTE] > Proof of delivery signed from the recipient's own phone counts for far more than a signature on the courier's device: it identifies who received, not who delivered. **Does it work without signal?** It sends once back in coverage; the recipient signs from their own phone. **What if nobody collects the delivery?** The attempt is logged with its time, which is what gets disputed. **Can I filter by incidents?** Yes, and it is the list worth reviewing weekly. ## Ejemplos **A last-mile operator loses several damage claims a month with no proof of delivery condition.** - Proof of delivery signed by the recipient - Certified photos when there is an incident → Claims are settled with the dated photo from the moment instead of splitting the cost. **Delivery evidence lives in the partner's app.** - Collects and stores what they provide in your own archive → Proof stops depending on someone else's system. **A client complains about a delivery from months ago.** - Keeps evidence beyond the closing of the order → You answer with proof rather than a status. **Each partner sends evidence in a different format.** - Requests specific documents to a single destination → What is received is comparable. **Nobody knows which partners are current.** - Checks everyone's status at once → You contract knowingly rather than reviewing afterwards. **A partner subcontracts and a stranger turns up.** - Records which firms are authorised per route → The delivery chain is known. --- --- id: KB-LG-001 url: https://app.codecontract.io/help/logistics/document-control-in-logistics idioma: en categoria: sector-logistica subcategoria: operadores audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-008, KB-CS-020] citadoPor: [KB-LG-002, KB-LG-003, KB-LG-004, KB-LG-005, KB-LG-007, KB-LG-008, KB-LG-009] --- # Document control in logistics _Documentation that moves with the goods and expires faster than in any other sector._ **Responde a:** transport document control · subcontracted haulier documentation · documents accompanying goods · where to start with logistics documentation In logistics, documentation has two features no other sector shares: it expires very fast, and much of it physically travels with the goods. Checking on arrival is no use; it has to be checked before loading. ## The three levels | Level | Documentation | Expires | | --- | --- | --- | | The company | Transport authorisations, insurance, tax clearance | Yes | | The vehicle | Roadworthiness tests, insurance, special authorisations | Yes, on different dates from each other | | The driver | Licences, professional competence, specific certifications | Yes, and it changes with turnover | > [!IMPORTANT] > With subcontracted fleets, checking has to be per person and per registration at loading time. A list from the subcontractor does not say who is in the van today or with which vehicle. ## What gets disputed afterwards Two things, always: whether it was delivered and in what condition. Both are documented at delivery or not at all, because afterwards it is the carrier's word against the customer's. **En corto** - Proof of delivery signed by the recipient, not by the deliverer. - Certified photos when there is an incident. - And a certified temperature record, if it travels chilled. > [!WARNING] > Each branch adds its own: dangerous goods require specific documentation, cold chain requires proving temperature, and customs requires the accompanying paperwork to be right first time or the goods sit stranded at a daily cost. > [!NOTE] > A 30-day expiry warning across a subcontracted fleet is what avoids the classic lorry arriving with an inspection that lapsed last week. **Can I check it at the bay?** Yes, from a phone, and that is precisely the use case. **What about one-off hauliers?** A quick case with the essentials: insurance and authorisation. **Does it serve for a transport inspection?** It is exactly what gets shown. ## Ejemplos **An operator with 35 subcontracted hauliers turns lorries away at the gate every week.** - One case per haulier, with vehicles and drivers - Checking from a phone before loading → Gate rejections disappear because the problem is visible three weeks earlier. **Each job's documentation lives in an email.** - Gathers a file per job → It is consulted without searching inboxes. **A client asks about a shipment from a year ago.** - Keeps the file with its date → You answer without reconstructing. **Each operator keeps their own material separately.** - Centralises documentation in one place → The answer does not depend on who is in. **Driver documentation expires without warning.** - Records expiries per person → The warning arrives before the job. **A partner delivers without their documentation current.** - Checks the status before assigning them a load → The gap shows before loading. --- --- id: KB-CS-028 url: https://app.codecontract.io/help/logistics/cold-chain-and-sensitive-goods idioma: en categoria: sector-logistica subcategoria: frigorifica audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-020, KB-CS-019] citadoPor: [KB-IU-002, KB-CS-031] --- # Cold chain and sensitive goods _Proving the temperature held, not just that the lorry arrived._ **Responde a:** transport temperature records · cold chain break claim · refrigerated transport documentation · goods temperature traceability In refrigerated transport, delivery is not enough: you have to prove the temperature held for the whole journey. And that proof, unless dated by a third party, is a record anyone could have edited afterwards. ## The three modules | What | Module | When | | --- | --- | --- | | Refrigeration equipment documentation and servicing | Trackline | At onboarding, with expiry | | Delivery with the recipient's sign-off | Consigne | On every delivery | | Journey temperature record | SmartCheck | Certified at journey close | > [!IMPORTANT] > Certifying the temperature record at journey close is what turns an editable file into evidence. Without it, facing a spoiled-goods claim you hold a file that says what suits you and that the other side can reasonably dispute. ## Where the chain breaks, in practice **En corto** - At loading and unloading, not on the road. - In an equipment failure nobody recorded. - In a vehicle change mid-route. All three share something: they happen at a specific moment that can be documented. A certified photo of the temperature recorder at loading and unloading covers most disputes. ## Frameworks cited Hygiene rules applicable to food transport, requirements for refrigeration equipment and installations, and — for medical or pharmaceutical products — the corresponding good distribution practices. Which temperatures and records your product requires is confirmed by your adviser or certification body. > [!WARNING] > If the refrigeration unit's service is overdue and there is an incident, the argument stops being about temperature and becomes about why it was on the road like that. Marking that service with a long warning is cheap. **Is the equipment's own record enough?** It is worth more certified at journey close, with a third party's date. **What if the incident happened at the client's warehouse?** That is why documenting unloading matters: it narrows where it happened. **Does it serve for an insurance claim?** It is the kind of evidence asked for; confirm the required format with your insurer. ## Ejemplos **A refrigerated carrier loses a spoiled-goods claim with no way to prove the temperature.** - Certifies the record at each journey close - Certified photo of the recorder at loading and unloading → The next claim is narrowed to unloading at the client's warehouse, with dated evidence. **The temperature log lives in the lorry's unit.** - Collects and stores the log on completion → The proof reaches the file. **There is a dispute about where the chain broke.** - Records the condition at each handover → The dispute closes on data. **Goods arrive out of range and are accepted anyway.** - Records the incident on receipt → The acceptance is explained. **A client asks for a specific shipment's log.** - Checks that shipment's file → You answer per shipment. **Nobody reviews incidents until there is a problem.** - Reviews them periodically → Patterns show before the incident. --- --- id: KB-LG-002 url: https://app.codecontract.io/help/logistics/customs-and-international-trade-documentation idioma: en categoria: sector-logistica subcategoria: aduanas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-CS-020] citadoPor: [KB-LG-009, KB-LG-011, KB-LG-015, KB-LG-022] --- # Customs and international trade _Where badly prepared paperwork does not delay: it strands the goods and costs by the day._ **Responde a:** customs clearance documentation · goods stuck at customs over paperwork · certificate of origin export · documents to export goods At customs, documentation differs from everything else: there is no margin. An incomplete document does not generate an email asking for clarification, it generates stranded goods costing storage every day. ## Where each item comes from | Document | Who holds it | How long it takes | | --- | --- | --- | | Invoice and packing list | You | Immediate | | Certificate of origin | Chamber or competent authority | Days | | Health or technical certificates | The manufacturer or a body | Days or weeks | | Transport documentation | The forwarder or the carrier | At booking | > [!IMPORTANT] > What takes longest is almost never yours: it is what depends on a third party. Requesting it when the deal is confirmed rather than when preparing clearance is the difference between shipping on time and paying storage. ## The commonest mistake Preparing each consignment from scratch. If you always export to the same markets with the same products, the document list changes little: built as a process, it fills in while the load is prepared rather than the night before. > [!WARNING] > Keep what was submitted with its date. If a discrepancy later arises about what was declared — and in international trade they do — you hold the exact set, not a folder you could have touched afterwards. ## Frameworks cited Import and export customs regimes, origin of goods and its certificates, health or technical requirements by product, and the documentary duties of the transport contract. What each market and tariff heading requires is confirmed by your forwarder or adviser: this only explains how to have it gathered in time. > [!NOTE] > If you work with a forwarder, give them scoped read access to the consignment instead of emailing documents. They see what they need and no loose copies remain. **Can I give the forwarder access?** Yes, read-only and scoped to that operation. **What if a non-EU supplier's document is missing?** That is what takes longest; the case at least proves when it was requested. **Does it serve for a post-clearance check?** That is exactly its purpose: what was submitted, with its date. ## Ejemplos **An exporter prepares each clearance the night before and pays storage twice a quarter.** - Builds the consignment as a process - Requests third-party items when the deal is confirmed → Customs holds disappear, and storage costs with them. **An operation's documents sit in three email threads.** - Gathers everything in the operation's file → What is there and what is missing is visible at once. **A review asks about operations from three years ago.** - Keeps each operation with its documents → You answer from the archive. **The forwarder changes and the history goes with them.** - Keeps its own archive of every operation → The change does not take the previous years. **The document evidencing origin is missing.** - Checks what is missing before treating the operation as closed → The gap is caught while the supplier still replies. **An invoice is corrected and the first one disappears.** - Keeps both versions with their dates → The correction can be explained. --- --- id: KB-LG-003 url: https://app.codecontract.io/help/logistics/dangerous-goods-transport idioma: en categoria: sector-logistica subcategoria: peligrosas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-CS-020, KB-LG-010] citadoPor: [KB-LG-018] --- # Dangerous goods transport _Where documentation does not accompany the shipment: it is part of being allowed to ship at all._ **Responde a:** dangerous goods transport documentation · which papers for hazardous goods · safety adviser documentation · driver hazmat training expiry With dangerous goods, documentation changes in nature: it is not an administrative requirement accompanying the shipment, it is part of the condition for being allowed to move it. Without it there is no delay, there is a consignment that cannot leave. ## The four levels | Level | What expires | Warning margin | | --- | --- | --- | | The company | Authorisations and its safety adviser | 90 days | | The vehicle | Specific certificates and inspections | 60 days | | The driver | Specific training, and it expires | 90 days: a course has to be arranged | | The consignment | Transport documents and product data sheets | Per shipment | > [!IMPORTANT] > Driver training fails most often, for the usual reason: it attaches to the person, not the vehicle or the company. A driver with expired training cannot carry that load however perfect the lorry and however current the company. ## What allows no improvisation **En corto** - The product's safety data sheet, up to date. - That whoever loads knows what they are loading and what it cannot travel with. - The consignment documentation, complete before departure. > [!WARNING] > Here a documentary failure does not end in a fine: it can end in an accident affecting people who did not choose to be nearby. It is the sector with the least room for "we will sort it later". ## Frameworks cited The European agreement on international carriage of dangerous goods by road, the safety adviser role and its duties, specific driver training, and substance classification and labelling. What applies to your particular goods and to what extent is confirmed by your safety adviser — who should also validate your procedure. > [!NOTE] > A 90-day warning is not excessive in this sector: renewing training means a place on a course, and in peak season there are none at fifteen days' notice. **Can I check at the loading bay?** Yes, and that is exactly where it belongs: before loading. **What if I subcontract the transport?** The haulier's documentation is your problem while they carry your goods. **Does it serve for an inspection?** It is the cross-check requested: company, vehicle, driver and consignment. ## Ejemplos **A shipper finds at the bay that the driver's training expired a month ago.** - 90-day warnings per driver, not per company - Checking at the bay before loading → Next time the problem surfaces three months earlier, with time to arrange the course. **The documentation that travels is prepared at the last minute.** - Checks what is missing before loading → The lorry does not leave with a gap. **The driver carries the paper and it gets wet or lost.** - Also carries it accessible from a phone → A lost paper stops halting the job. **The driver's training expires en route.** - Records expiries per person → The warning arrives before assigning the job. **A load is taken without checking its data sheet.** - Checks the sheet before accepting the load → The decision is taken with the document in view. **A check asks about a job from months ago.** - Keeps a file per job → You answer from the record. --- --- id: KB-LG-004 url: https://app.codecontract.io/help/logistics/managing-fleet-documentation idioma: en categoria: sector-logistica subcategoria: flotas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-CS-010] citadoPor: [KB-LG-010, KB-LG-014] --- # Documentation for your own fleet _Vehicles expiring on their own schedules and drivers who rotate._ **Responde a:** own fleet document control · vehicle inspection and insurance expiries · company driver documentation · managing vehicle and driver paperwork Your own fleet looks easier to control than a subcontracted one, and in one sense it is: they are yours. In another it is worse: nobody warns you from outside, and each vehicle's dates coincide with no other's. ## What expires, and not together | What | How often | Who renews it | | --- | --- | --- | | Vehicle roadworthiness test | By age and type | You, by appointment | | Insurance | Annually | Your broker | | Transport authorisations | By regime | The authority | | Driver licence and training | By type | The driver themselves | | Specific training where applicable | By cargo | A course, with limited places | > [!IMPORTANT] > The last column decides the warning margin. What you renew yourselves tolerates fifteen days; what depends on an appointment, an authority or a course with limited places needs ninety. Setting the same warning for everything guarantees being late for whatever takes longest. ## What always gets forgotten **En corto** - Vehicles used rarely: they expire the same and nobody looks. - Temporary drivers: they rotate and their training goes with them. - Trailers and equipment, with their own dates. > [!WARNING] > A vehicle on the road with an expired inspection is not an administrative problem: it is direct liability if there is an accident, and your insurer may have something to say about it. ## What changes versus a calendar A calendar warns; it does not report status. The difference shows when someone asks "can this lorry go out today?": on a calendar you check five separate entries, and with one case per vehicle it is a single answer. > [!NOTE] > If you have both own and subcontracted fleet, build them the same way. Making the check identical for both is what avoids the blind spot of "we already know ours are fine". **One case per vehicle or per fleet?** Per vehicle, by registration. That is what lets you check before departure. **What about non-permanent drivers?** Same as permanent: their documentation goes with the person. **Does it help at a roadside check?** What is shown there are the vehicle's papers; this is about never reaching that point with something expired. ## Ejemplos **A company with 14 vehicles tracks expiries in a shared calendar.** - One case per registration, with driver and equipment - Different warnings depending on who renews each item → The transport manager answers whether a lorry can go out at a glance, instead of cross-checking five entries. **Each vehicle's papers sit in its glovebox.** - Captures and stores them in the vehicle's file → They are consulted without going to the yard. **A vehicle inspection falls due and nobody notices.** - Records expiries per vehicle → The warning arrives before the date. **A vehicle with something expired is assigned.** - Checks the status before assigning it → The job does not go out with a gap. **A vehicle changes driver and the papers do not.** - Separates vehicle records from person records → Each file follows what it belongs to. **A client asks for the fleet's documentation.** - Checks each vehicle's file → It is handed over without reassembling anything. --- --- id: KB-LG-005 url: https://app.codecontract.io/help/logistics/returns-and-reverse-logistics idioma: en categoria: sector-logistica subcategoria: inversa audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-NO-003] citadoPor: [KB-LG-006] --- # Returns and reverse logistics _What comes back also needs documenting, and almost never is._ **Responde a:** documenting goods returns · reverse logistics traceability · condition of a returned product · who is responsible for a returned product All the documentary effort goes into what leaves. What comes back arrives uncontrolled, piles up in a warehouse corner and surfaces in an argument three months later: what condition did it return in, who collected it, and is what came back what was sent. ## What to document on receipt **En corto** - What condition it arrives in, with photos if it may be disputed. - What it exactly is: reference and batch, not "a box". - Who brought it and when. | Type of return | What gets argued later | | --- | --- | | Defective product | Whether the defect was original or from use | | Order error | Whether it came back complete and sellable | | End of life or recall | Where it ended up and who handled it | | Hired equipment | What condition it returned in versus how it left | > [!IMPORTANT] > The last row is the costliest and the most forgotten. Hired equipment returning damaged with no photos of departure or arrival is an argument almost always lost, because whoever hired it has no evidence to the contrary either. ## If what comes back is waste It changes nature: it stops being a return and becomes waste with its own management and traceability duties. Confusing the two is what produces piles of material nobody knows how to dispose of. > [!WARNING] > If you handle returns of product that ends up as waste, check with your adviser at what point the regime changes. It is not a warehouse question: it is a question of which duties apply to you from that moment. > [!NOTE] > Photographing hired equipment on departure costs a minute and is the only thing that sustains the return conversation. It is the same case as prior condition on a site. **Is it worth it for small returns?** For those that get disputed, yes. For the rest, recording what came back suffices. **What if it arrives unannounced?** Documenting receipt matters even more: nobody else did. **Does it help claim against the carrier?** Dated photos of receipt are what is asked for. ## Ejemplos **A machinery hire company argues monthly about damage on returned equipment.** - Certified photos on departure and on return → Arguments close by comparing two dated series, and repairs are paid by whoever caused them. **A return arrives without knowing which shipment it belongs to.** - Records the return against the original shipment → The order's history stays complete. **There is a dispute about the condition goods came back in.** - Captures the condition on receipt → The dispute closes on the record. **Returns are noted on a separate sheet.** - Records them in the order's file → There is one picture of the order. **A client asks about a return from months ago.** - Checks that order's file → You answer without searching email. **Nobody knows how many returns come from one client.** - Checks the history per client → The pattern shows with data. --- --- id: KB-LG-006 url: https://app.codecontract.io/help/logistics/ecommerce-and-order-fulfilment idioma: en categoria: sector-logistica subcategoria: ecommerce audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-020, KB-LG-005] citadoPor: [KB-LG-012] --- # E-commerce: high volume, thin margins _Thousands of shipments where each incident costs more than the order._ **Responde a:** documenting ecommerce deliveries · delivery incidents in online retail · proof of delivery ecommerce · online retail returns In e-commerce the problem is not each shipment: it is the proportion. With three thousand orders a month, one per cent of incidents is thirty disputes, and each costs more in handling than the margin on the order that caused it. ## Where the margin goes | Incident | What is disputed | What closes it | | --- | --- | --- | | "It never arrived" | Whether it was delivered and to whom | Proof of delivery signed by the recipient | | "It arrived broken" | Whether it left that way or broke in transit | A certified photo at picking | | "This is not what I ordered" | What went into the box | The picking record with its batch | | Return in poor condition | What condition it came back in | A photo on receiving the return | > [!IMPORTANT] > At this volume you cannot document everything in detail: you document what gets disputed. Photographing three thousand orders is impossible; photographing high-value ones or those from customers with an incident history is half an hour a day. ## The rule that makes volume sustainable Document by exception. The normal flow leaves the minimum trail — what left, when and to where — and detail is reserved for the stretches where money is actually lost. Trying to document everything equally ends with nothing being documented. **En corto** - Proof of delivery always: it is cheap and closes half the disputes. - A picking photo only for high-value orders. - And a photo on receiving every return, which is where most is lost. > [!WARNING] > Watch the last one: returns are e-commerce's blind spot. They leave documented and come back with nothing, and three months later nobody can say what condition that now-unsellable product arrived in. > [!NOTE] > If you use subcontracted couriers, proof of delivery signed by the recipient counts for far more than the courier's own record: it identifies who received, not who delivered. **Is it worth it for low-value orders?** Proof of delivery yes, always. The rest no. **What about pickup-point deliveries?** You document delivery to the point; what happens after is the point's. **Can I filter by incidents?** Yes, and it is the list worth reviewing weekly. ## Ejemplos **An e-commerce operator absorbs the cost of thirty damaged returns a month.** - Certified photo on receiving every return → Damaged ones are claimed against the carrier with evidence, instead of being written off. **Volume makes reviewing delivery by delivery impossible.** - Reviews only what falls outside the pattern → Effort goes where things actually fail. **A client complains and there is no proof of delivery.** - Keeps evidence of every delivery → Refunding stops being the only way out. **Each delivery partner works differently.** - Agrees what is captured on each delivery → The evidence is consistent. **Complaints arrive weeks later.** - Keeps evidence beyond the order → The answer does not depend on someone else's retention. **Nobody knows which route generates most incidents.** - Checks incidents by route → The cause is tackled where it sits. --- --- id: KB-LG-007 url: https://app.codecontract.io/help/logistics/damaged-goods-proving-what-happened idioma: en categoria: sector-logistica subcategoria: terrestre audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-CS-008, KB-LG-018] citadoPor: [KB-CS-031, KB-LG-012, KB-LG-016, KB-LG-017] --- # Damaged goods: proving what happened _Someone's phone photo is not evidence. What makes it evidence is when it was taken._ **Responde a:** damaged freight claim · proving the load left in good condition · noting reservations on the delivery note · who is liable for transport damage When goods arrive damaged, the argument is never about the damage: it is about where it happened. And that argument is won by whoever can show the state of the load at every handover, with a date that does not rest on their word. ## The four handovers you must be able to document | Handover | What is recorded | Who usually holds it | | --- | --- | --- | | Departure from origin | Condition, seal, temperature if relevant | The shipper | | Loading onto the vehicle | Stowage, number of packages | The carrier | | Unloading or change of mode | Condition on arrival, incidents | The intermediate warehouse | | Final delivery | Receiver's reservations, if any | The consignee | > [!IMPORTANT] > The missing link is usually the third. When there is a vehicle change or a warehouse stop, almost nobody records condition — and that is exactly the leg where liability can be shared or dodged. ## What makes a photo count 1. **It is linked to the shipment, not loose on a phone** — A photo with no context does not say which shipment it belongs to. 2. **It carries a date that cannot be moved** — That is what shuts down the "that photo is from later" argument. 3. **It comes with who took it** — Evidence without an author carries half the weight. 4. **And it exists when everything is fine too** — Photographing only damage means the absence of a photo proves nothing. > [!WARNING] > The fourth point is what changes the outcome. If photos only exist when there is a problem, you cannot prove it left in good condition: only that it arrived damaged. Always recording departure is what puts you on the right side of the burden of proof. ## Reservations at delivery The receiver's note at the moment of delivery is, in practice, the most valuable document in the whole chain — and the one most often lost, because it is handwritten on a note nobody scans afterwards. If delivery is signed on a phone, the reservation is written down, timed, and reaches the office before the truck does. **En corto** - Condition recorded at every handover, not just at the end. - A provable date, not the file's. - And the receiver's reservations, written where they will not be lost. > [!NOTE] > Claim windows are short and vary by transport mode. What does not vary is that they run from delivery: the sooner the incident reaches whoever handles it, the more room is left. **What if the damage shows up days later?** You can still claim, but what was recorded at delivery weighs heavily. **Does sealing help here?** Yes: it fixes that the file existed on that date, which is exactly what gets disputed. **Is it needed for every shipment?** For valuable or risky ones, yes. For the rest, at least delivery. ## Ejemplos **A shipper faces a claim over damaged pallets and only has the consignee's photos.** - Starts recording condition at departure for every shipment - Captures receiver reservations on the phone-signed delivery → On the next claim it shows the load left in good order and liability shifts. **Goods arrive damaged and nobody photographed the despatch.** - Captures the condition at each handover → You can narrow down where it happened. **The damage is found on unpacking, days later.** - Records the condition on receipt and on opening → The two moments stay separate. **Each party maintains it was fine when they let go.** - Compares the records of both handovers → The dispute closes on data. **The claim goes out late because evidence had to be hunted.** - Has the evidence ready in the file → The claim goes out in time. **A damaged delivery is accepted with no record.** - Notes the incident at the moment → Acceptance does not close the door to claiming. --- --- id: KB-LG-008 url: https://app.codecontract.io/help/logistics/subcontracting-transport-to-partners idioma: en categoria: sector-logistica subcategoria: operadores audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-001, KB-CS-008] citadoPor: [KB-LG-010, KB-LG-025] --- # Subcontracting transport to partners _Peak season is covered with owner-drivers and partners. Liability is not subcontracted._ **Responde a:** partner haulier documentation · subcontracting deliveries to owner-drivers · requirements to work with an external carrier · controlling transport subcontractors Almost no operator covers its peaks with its own fleet. You lean on regular partners and, when they run out, on whoever is free that week. The problem is that the load is still yours towards the customer, and their paperwork is yours towards an inspector. ## The minimum before giving them a load | Document | What happens if missing | Expires | | --- | --- | --- | | Transport authorisation | Work without legal cover | Yes | | Liability insurance | The damage ends up on your policy | Yes, usually annual | | Driver registration and contributions | Joint liability | Every month | | Training and specific permits | Depends on the goods | By type | > [!IMPORTANT] > The third row surprises people: it does not expire yearly, it changes monthly. A partner who was perfect in March may not be in June, and that is exactly the check you cannot do by hand every time. ## How to organise it without slowing operations 1. **A live list of approved partners** — With document status visible before assigning, not after. 2. **Onboarding as a process, not a phone call** — Everything requested at once, with automatic chasing until complete. 3. **Automatic checking of what expires** — Especially the monthly items, where manual control fails. 4. **And a clear rule for the urgent case** — What is acceptable to release a load today and what never is, decided calmly. > [!WARNING] > The fourth prevents the real conflict. In peak season someone will want to give a load to an incomplete partner "just this once". If the rule is not written beforehand, it gets decided under pressure, and nobody defends that decision later. ## What will be asked of you **En corto** - Your large customers: proof that you control who you subcontract. - An inspection: the paperwork of whoever was driving that day. - And your insurer: that the chain was in order when it happened. All three are answered with the same thing: the partner's document status on a specific date. If that only exists as folders, it takes days; if it is linked to each load, minutes. > [!NOTE] > It applies equally to an operator subcontracting another operator, to parcel work with self-employed couriers, and to a shipper contracting directly. Who asks changes, what you must be able to show does not. **Can we ask for monthly documents without nagging?** Ask once and renew only what expires; the chasing runs automatically. **What if the partner subcontracts in turn?** The classic blind spot: require them to declare it and control that second level. **Is a signed agreement enough?** The agreement allocates liability; it does not replace checking they are current. ## Ejemplos **An operator covers peak season with twelve partners and checks documents by email.** - Turns onboarding into a process and automates the monthly check - Writes the urgent-case rule before the season → Assigns loads seeing document status in the moment, without slowing operations. **Work is subcontracted to somebody whose papers are not current.** - Checks the status before assigning a load → The gap shows before the job. **The client asks about the partner who did the haul.** - Checks that partner's file → You answer with a list rather than an enquiry. **Each partner sends their material whenever they remember.** - Requests and chases automatically → Follow-up occupies nobody. **A partner subcontracts in turn.** - Records which firms are authorised → The chain stops growing unnoticed. **Less is required of the partner than is required of you.** - Passes the same list downwards → The gap stops sitting on your balance sheet. --- --- id: KB-LG-009 url: https://app.codecontract.io/help/logistics/customs-warehousing-and-held-goods idioma: en categoria: sector-logistica subcategoria: aduanas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-002, KB-LG-001] citadoPor: [KB-LG-011, KB-LG-013, KB-LG-024] --- # Customs warehousing and held goods _Goods that are there but cannot move, and paperwork that decides how long they stay._ **Responde a:** goods held at customs documentation · customs warehouse paperwork · why a container gets held · speeding up customs clearance A customs hold costs money every day: storage, container demurrage, deliveries that fall through. And it is rarely about the goods: it is because a paper is missing, carries a different figure, or arrives late. ## The usual causes, in order | Cause | What triggers it | Cost to fix | | --- | --- | --- | | Discrepancy between documents | Invoice, packing list and bill of lading disagree | Hours, if you can reach whoever issued it | | A missing certificate | Origin, health, conformity | Days, if it must be requested at origin | | Disputed classification | The declared tariff heading | It varies, and sometimes it pays to ask first | | Random control | Nothing you did wrong | However long the inspection takes | > [!IMPORTANT] > The first is the commonest and the most avoidable. Three documents describing the same goods with three descriptions or three weights create a hold nobody would argue about if the figures matched. ## How to prevent it before shipping 1. **Check the three documents agree** — Description, quantity, weight and value. While the shipment is still at origin. 2. **Check which certificates the destination requires** — They vary by country and product, and sometimes change without notice. 3. **Keep everything in the shipment's file** — Not in the agent's inbox nor the supplier's: somewhere both can reach. 4. **And keep what origin sends exactly as it arrives** — The original, not a retyped version: if there is a discrepancy, it is compared against it. > [!WARNING] > The blind spot is the customs agent. They do good work, but if all documentation lives in their inbox, when a hold happens you depend on them being available to find out what occurred. With a shared file, you see it yourselves. ## Once it is held **En corto** - First, establish the exact cause rather than assuming it. - Second, who can issue the missing document and how long they take. - And third, tell the end customer before they ask. The third does not shorten the hold but it decides whether the customer experiences it as a setback or as your failure. > [!NOTE] > Every held day has a measurable cost in storage and demurrage. It is worth recording: it is the argument that convinces people to spend half an hour checking documentary consistency before each shipment. **Can you tell in advance if goods will be held?** Not for random control; for the other three causes, almost always yes. **Is clearance history useful?** Very: the same products with the same suppliers repeat the same problems. **What if the hold is over classification?** It is a technical argument: detailed product documentation to hand is what helps. ## Ejemplos **An importer keeps getting holds and always hears from the agent two days later.** - Centralises shipment documentation in a shared file - Checks the three documents agree before shipping → Discrepancy holds disappear and the rest are spotted the same day. **A consignment has sat for weeks and its owner says they did not know.** - Records every notice sent, with its date → The storage invoice is explained by the trail. **Nobody knows what is missing for a consignment to leave.** - Shows which document is missing and whose it is → The owner acts without a phone call first. **There is a dispute about the condition goods arrived in.** - Keeps what was checked on entry → The dispute closes on the record. **A consignment has sat a year and nobody answers.** - Flags what has gone too long without movement → The case is faced at one month rather than one year. **The owner changes forwarder and nobody knows who to write to.** - Records the contact for each consignment → The notice reaches somebody who exists. --- --- id: KB-LG-010 url: https://app.codecontract.io/help/logistics/driver-documentation idioma: en categoria: sector-logistica subcategoria: flotas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-004, KB-LG-008] citadoPor: [KB-LG-003] --- # Driver documentation _Licences, mandatory training and fitness: what expires per person, not per vehicle._ **Responde a:** driver licence control for a fleet · driver cpc expiry · mandatory training for professional drivers · driver medical fitness Fleet documentation is nearly always controlled per vehicle: insurance, roadworthiness test, maintenance. The one that causes most trouble is the other kind, the one that goes with the person, because it expires on different dates for each and nobody sees it until a driver cannot go out. ## What expires per driver | Document | Typical frequency | What happens if it lapses | | --- | --- | --- | | Driving licence of the relevant category | By category and age | They cannot drive that vehicle | | Mandatory professional training | Periodic | They cannot carry out professional transport | | Medical or fitness certification | Periodic, more frequent with age | Same, and with liability for the company | | Cargo-specific training | By type of load | They cannot carry that particular cargo | > [!IMPORTANT] > The fourth row slips most because it does not apply to everyone: only to whoever carries that cargo type. When a route has to be covered by whoever is free, it is easy to assign someone who can drive the lorry but not that load. ## How to control it without a spreadsheet 1. **One file per driver, with their due dates** — Separate from the vehicle, because it travels with the person, not the lorry. 2. **Warnings with enough margin to renew** — Months, not days: renewing a medical takes time and depends on third parties. 3. **Check before assigning, not after** — Especially when covering absence or a peak. 4. **And the same for partners' drivers** — Their documentation matters to you just as much, even though they are not yours. > [!WARNING] > Beware the long-serving driver. Whoever has been with the company fifteen years is exactly whose expiry nobody checks, because "he's got everything". That profile produces the most surprises. ## What gets asked in a roadside check **En corto** - That the driver could drive that vehicle that day. - That they held current training for that cargo. - And, if there is an accident, all of the above with dates. All three are answered from a phone if the driver's file is current. And all three are the company's responsibility, not only the driver's. > [!NOTE] > It applies equally to in-house fleets not in the transport business: sales staff, service engineers, site vehicles. Which documents apply changes; that they expire per person does not. **Can we keep a copy of their licence?** With a justified purpose and appropriate retention, yes; it is employment documentation. **What about seasonal drivers?** Same check, and it is where the rush is greatest: a fast lane helps. **Is warning the driver enough?** Necessary but not sufficient: checking before assigning is the company's job. ## Ejemplos **A company covers an urgent route with whoever is free and the driver is stopped en route.** - Builds a per-driver file with due dates and warnings - Checks before assigning, not after → Stops assigning routes to drivers who cannot carry that specific cargo. **A driver goes out with expired training.** - Checks per person before assigning the job → The job does not go out with a gap. **A licence is renewed and nobody updates the file.** - Records the renewal on receipt → The file reflects reality. **A new driver joins on the day of the job.** - Checks what they are missing before assigning them → Onboarding is resolved before departure. **The documentation sits on the traffic manager's phone.** - Stores it in the driver's file → It stops depending on one person. **A client asks for the documentation of the driver who delivered.** - Checks that person's file → It is provided without searching. --- --- id: KB-LG-011 url: https://app.codecontract.io/help/logistics/documents-for-a-sea-shipment idioma: en categoria: sector-logistica subcategoria: maritimo audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-002, KB-LG-009] citadoPor: [KB-LG-013, KB-LG-017] --- # Documents for a sea shipment _Which document does what, which can be reissued, and which you must never lose sight of._ **Responde a:** documents for a sea container · original bill of lading · what is container vgm · paperwork to ship goods by sea A sea shipment generates half a dozen documents that people treat as interchangeable, and they are not: one of them is a title giving the right to collect the goods, and the rest are information. Confusing them is what turns a delay into a loss. ## What each one does | Document | What it is | If it is lost | | --- | --- | --- | | Bill of lading | Contract, receipt and — in original form — title to the goods | The serious problem: a bank guarantee may be needed | | Booking and confirmation | Your slot on the vessel | Request it again from the forwarder | | Verified gross mass declaration | The container's certified weight | Reissued, but before the carrier's cut-off | | Packing list and invoice | What is inside and its value | Reissued; make sure they agree with each other | | Origin or health certificates | Destination country requirements | Requested from the issuing body, and that takes time | > [!IMPORTANT] > The real difference is in the first row. An original bill of lading **is** the goods for delivery purposes: whoever presents it collects them. That is why it travels through banking channels in many transactions, and why releasing against a copy "because the customer already paid" is the classic way to lose both the cargo and the payment. ## What to keep linked to the shipment **En corto** - The documents, with their version and who issued them. - Who each was sent to, and when. - The shipping instructions you gave, which is what gets compared if something goes wrong. - And incidents during the voyage, with dates. ## The three costliest mistakes 1. **Figures that disagree across documents** — Different weight, description or package count on invoice, packing list and bill of lading: the number one cause of holds at destination. 2. **Missing the documentary cut-off** — The cut-off is set by the carrier and is not negotiable: a container without its paperwork in time does not load, even sitting in the port. 3. **And assuming the destination requirement** — What worked on the last shipment to that country may have changed; check per shipment, not by habit. > [!WARNING] > The nuance nobody deduces from their first shipment: the days the container sits at destination and the days you use the container itself are different things, counted separately and invoiced by different parties. A clearance resolved quickly can still generate container cost if nobody returns it, and that invoice arrives weeks later, when nobody remembers the shipment. > [!NOTE] > If you work with a forwarder, much of this documentation lives in their system. Keep your own copies: in a claim, the forwarder's documentation is their version of events, and you need yours. **Can goods ship without the original bill of lading?** There are arrangements without an original; they are agreed before shipping, not once the cargo is at destination. **Who declares the verified gross mass?** The shipper, and the carrier will not load without it. **Is it worth sealing these documents?** For those supporting a claim, yes: it fixes what they said and on what date. ## Ejemplos **An exporter sends the invoice with one weight and the packing list with another.** - Checks the three documents agree before the cut-off - Keeps its own copy of the whole shipment, not just the forwarder's → The container ships without incident and discrepancy holds stop recurring. **The shipment's documents arrive from three different parties.** - Gathers everything in the shipment's file → What is there and what is missing is visible at once. **A document is missing and the goods sit still.** - Checks what is missing before departure → The gap is caught before the port. **A client asks about a shipment from a year ago.** - Keeps the file with its date → You answer without phoning the forwarder. **A document is corrected and the previous one disappears.** - Keeps both versions with their dates → The correction can be explained. **Every shipment is prepared from scratch.** - Reuses what repeats per destination → The second shipment costs half. --- --- id: KB-LG-012 url: https://app.codecontract.io/help/logistics/proof-of-delivery-in-parcel-services idioma: en categoria: sector-logistica subcategoria: paqueteria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-007, KB-LG-006] citadoPor: [KB-LG-021, KB-LG-025] --- # Proof of delivery in parcel services _A scrawl on a screen or a photo at a doorway: what each proves when the customer says it never arrived._ **Responde a:** parcel proof of delivery · customer says the order never arrived · is a doorstep photo enough · delivery to a neighbour dispute In parcel work the argument is not whether the parcel left: it is whether it reached the right person. And the usual proofs carry very different weight, even though the system shows them all as "delivered". ## What each proves | Proof | What it evidences | Where it is weak | | --- | --- | --- | | On-screen signature | That someone signed there | A scrawl identifies nobody on its own | | Recipient's name and ID | Who collected it | Depends on the courier actually asking | | Photo at the delivery point | That the parcel was left there | It does not prove the recipient took it | | One-time code | That whoever received it had the code | Only if it is genuinely required, not skipped | > [!IMPORTANT] > The third row gives the most false confidence. A photo of the parcel on the doormat proves the courier arrived and left it — not that the addressee received it. For valuable shipments, that photo does not close a claim: it opens it looking tidier. ## What decides a consumer claim **En corto** - Whether the addressee authorised leaving it without a signature, and where that authorisation is recorded. - If it went to a third party, who they were and whether they were authorised. - The exact time and delivery point, not just the day. - And whether there were previous attempts, with their records. With a business customer you argue the contract; with a consumer, the burden of proof tends to fall on whoever delivers. The more valuable the shipment, the more it pays to step up: a code, an ID, or an identified signature. > [!WARNING] > The point that wrong-foots people coming from pallet freight: at a residential address, **delivering to a neighbour is not delivering**, unless the addressee authorised it beforehand. Many claims that look absurd — "someone did take it" — are lost exactly there, and not over the fact but over being unable to show the authorisation. ## How to capture it without slowing the round 1. **Capture the proof at the moment and at the place** — From the phone, not back at the depot. 2. **Keep it linked to the shipment, not loose** — A photo in the courier's gallery is not proof of delivery. 3. **And retain it for the claim period** — Which is usually longer than the delivery system's memory. > [!NOTE] > Claim windows and who bears the burden of proof vary by shipment type, recipient and country. **Confirm that with your adviser or in the transport contract**; what is compared here is what each type of proof evidences in practice. **Is an on-screen signature enough?** It helps, and alone it identifies nobody. With a name or a code, much more. **What if the customer authorised leaving it at the door?** Then the photo is worth considerably more: what you must be able to show is the authorisation. **How long should proofs be kept?** Longer than the applicable claim period, with margin. ## Ejemplos **A courier firm loses a claim despite having a doorstep delivery photo.** - Starts requiring a one-time code on valuable shipments - Records the authorisation when a customer asks for no-signature delivery → Claims on expensive shipments start being settled with proof that actually identifies the recipient. **The on-screen signature does not say who signed.** - Records the name alongside the signature → Half the disputes disappear. **Delivery happens with nobody authorised and is signed anyway.** - Gives the courier a rule and records their decision → What was decided is documented. **The proof lives in the partner's system.** - Collects and stores what they provide → The proof stops depending on someone else. **A client complains months later.** - Keeps evidence beyond the order → The answer exists when the complaint arrives. **The delivery arrives damaged and there is no photo.** - Captures a photo when the delivery is not clean → The condition is documented as it happens. --- --- id: KB-LG-013 url: https://app.codecontract.io/help/logistics/working-with-a-freight-forwarder idioma: en categoria: sector-logistica subcategoria: transitarios audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-011, KB-LG-009, KB-LG-023] citadoPor: [KB-LG-015, KB-LG-019] --- # Working with a freight forwarder _A good part of your documentation lives in their system, and that is fine until the day it is not._ **Responde a:** documentation held by the forwarder · changing customs agent · the forwarder holds my documents · which shipment copies should i keep A good forwarder takes work off you: they prepare, file, resolve and store. The side effect is that over time your shipments' documentation lives in their platform and not in yours — and that only becomes apparent when something is needed and they are unavailable, or when you decide to change. ## What should also live on your side | Document | Why yours | When it is missed | | --- | --- | --- | | Bill of lading and transport documents | It is the proof of the operation | In a claim, and in a hurry | | Declarations and clearance receipts | They evidence what was declared and when | In a review, months later | | Origin or health certificates | You requested them, or they did on your behalf | On the next shipment to the same country | | The instructions you gave them | It is what gets compared if something went wrong | When deciding whose fault it was | > [!IMPORTANT] > The last row is the one hardly anyone keeps and the only one that defends you. In an incident, the forwarder's documentation tells **their** version: what they did and when. What says what you asked for is your instruction, and if it lived in an email from someone who has left, it does not exist. ## How to work without duplicating effort 1. **One file per shipment, with the essentials** — Not everything they handle: the bill of lading, invoice, packing list and what you instructed. 2. **Ask for copies at closing, not when claiming** — A closed shipment is documented in two minutes; an eight-month-old one takes two days. 3. **Keep what they send exactly as it comes** — Without retyping or reassembling: if there is a discrepancy, it is compared with the original. 4. **And record incidents on the shipment** — Delays, holds, extra costs: it is what supports the annual conversation with them. > [!WARNING] > The blind spot appears when you change forwarder. Their platform is theirs: access ends when the relationship ends, and with it your shipment history. **Nobody warns you of that on the day you sign with someone else** — it is discovered when someone asks for a clearance from two years ago and there is nowhere left to look. Taking copies before ending the relationship costs an afternoon; afterwards it can be impossible. ## What improves the relationship as well as protecting you **En corto** - Clear written instructions: half of all incidents are interpretation. - Cargo details consistent across documents, which is what they cannot fix for you. - And the incident history in front of you when tariffs are renegotiated. The third changes the annual conversation: moving from "things are so-so" to "three holds for discrepancies and two for certificates" is what gets the problem fixed instead of debated. > [!NOTE] > The same applies to customs agents, shipping agents and operators handling documentation for you. The procedure changes; that proof of what you asked for and what was done belongs on both sides does not. **Is keeping copies a sign of distrust?** No: their archive answers their obligations, not yours. **What if we use several forwarders?** All the more reason: it is the only place where the whole picture of your shipments exists. **How long should it be kept?** Longer than the review period applicable to those operations, with margin. ## Ejemplos **An importer changes forwarder and loses access to two years of clearance history.** - Before ending the relationship, downloads and files the shipments in its own records → It can answer a later review without depending on a company it no longer works with. **The forwarder keeps the history and you do not.** - Keeps its own archive of every operation → Changing partner does not take the years with it. **Instructions are given by phone.** - Asks for written confirmation and keeps it → What was agreed stops depending on two memories. **A document is missing and clearance goes ahead on a promise.** - Records what was promised and who asked → The broken undertaking is documented. **A client asks about an old operation.** - Checks its own file → You answer without depending on the forwarder. **Three forwarders are used and each reports differently.** - Requests the information in an agreed format → What is received is comparable. --- --- id: KB-LG-014 url: https://app.codecontract.io/help/logistics/pharmaceutical-distribution-and-sensitive-goods idioma: en categoria: sector-logistica subcategoria: farmaceutica audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-031, KB-LG-004] citadoPor: [KB-IU-002] --- # Pharmaceutical distribution and sensitive goods _Here documentation does not accompany the shipment: it is part of the product, and without it the product is worthless._ **Responde a:** pharmaceutical distribution documentary requirements · temperature-sensitive product transport · pharmaceutical batch traceability · who may handle pharmaceutical product In most sectors, a documentary failure is an administrative problem solved by asking for the paper again. In pharmaceutical and medical goods distribution it is not: if you cannot evidence the conditions a batch was kept in, that batch cannot be sold, however perfect it is. ## The four things to evidence for every batch | What | Why | Where it is lost | | --- | --- | --- | | Where it came from and where it went | It is the basis of any recall | When dispatch is recorded by customer rather than by batch | | The conditions in transit and storage | It defines whether the product is still fit | Records exist and are not linked to the batch | | Who handled it and with what qualification | Some functions cannot be done by anyone | It is checked at hiring and not afterwards | | What was done about a deviation | The reaction is judged as much as the event | It is resolved by phone and leaves nothing | > [!IMPORTANT] > The second row decides the value of the goods and is the worst linked. Holding a lorry's temperature record is worth nothing if you cannot say **which batches were inside**: the record proves the vehicle stayed in range, not that this particular product did. That link is the whole job, and it is what goes wrong when recording is by vehicle rather than by shipment. ## The deviation, where everything is decided 1. **Recorded at the moment, with the real time** — And the affected product segregated before anything is decided. 2. **Decided against criteria written beforehand** — Improvising criteria during the deviation is what cannot be defended afterwards. 3. **Decided by whoever holds that function** — Not by whoever happens to be in the warehouse at that hour. 4. **And the decision recorded, not just the reading** — What was released, what was blocked and why, with a name. > [!WARNING] > The nuance that separates this sector from the rest: **documentation does not follow the product, it travels with it**. Product arriving without complete documentation is not product awaiting paperwork — it is product that cannot be released until resolved, and meanwhile it occupies space, expires and costs. Which is why here the record is taken at the door, not at the end of the day. ## What an inspection asks for **En corto** - The full history of a batch of their choosing, intake to dispatch. - Conditions on each leg, linked to that batch. - The period's deviations and what was decided in each. - And the qualification of whoever was involved, valid on those days. > [!NOTE] > Specific distribution requirements, required qualifications and which records must be kept depend on the product type and the country, and they get updated. **Confirm with your technical manager or the competent authority**; this describes where the documentary chain breaks in practice. **Is the carrier's record enough?** As data yes; you must be able to link it to your batches and keep it yourselves. **What if the customer detects the deviation on receipt?** Treat it the same: record, segregate and decide against criteria, even though the product has left your hands. **How long must it be kept?** Beyond the product's life, with margin: it is among the most requested. ## Ejemplos **A distributor keeps temperature records per vehicle rather than per shipment.** - Links each record to the batches that were inside - Writes the decision criteria before the next deviation → In an inspection it can evidence the conditions of that specific batch, not just the lorry's. **The temperature log is filed loose.** - Attaches it to the shipment on receipt → The log lives with the shipment it documents. **A client asks for a specific shipment's traceability.** - Checks that shipment's file → You answer per shipment. **Driver documentation expires without warning.** - Records expiries per person → The warning arrives before the job. **The range is breached and it is accepted with no record.** - Records the incident on receipt → The acceptance is explained. **A review asks about shipments from two years ago.** - Keeps the files with their dates → You answer from the archive. --- --- id: KB-LG-015 url: https://app.codecontract.io/help/logistics/air-cargo-what-changes-versus-road idioma: en categoria: sector-logistica subcategoria: aereo audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-013, KB-LG-002] citadoPor: [KB-LG-018] --- # Air cargo: what changes versus road _It travels faster and stops for different reasons: here what delays you is not traffic, it is security and paperwork._ **Responde a:** sending goods by air documentation · why is all my air cargo screened · difference between air and road freight · what the airline needs to load The first air shipment surprises nearly everyone: the flight takes four hours and the goods take four days. It is not the plane — it is everything that happens before it boards, and it runs on rules that road transport simply does not have. ## What changes versus a lorry | Aspect | By road | By air | | --- | --- | --- | | Who may hand over the cargo | Anyone | Depends on whether you are accredited in the security chain | | What is checked | The transport documents | The documents and, often, the cargo physically | | What drives the price | Weight | Weight or volume, whichever is greater | | What stops a shipment | An error in the transport document | Also packaging or a declaration that does not fit | | Room to correct | Hours | The flight leaves anyway: it waits for the next one | > [!IMPORTANT] > The first row decides your lead times and almost nobody knows it before their first shipment: **if your company is not accredited within the air cargo security chain, every shipment goes through physical screening**. That adds time, cost and sometimes means opening the packaging you prepared so carefully. Accreditation is applied for, takes its own process and cannot be improvised for Thursday's shipment — but it changes the whole operation for anyone shipping regularly. ## What to have ready before booking 1. **A real description of the goods, not a commercial one** — «Samples» is not a description and generates the most queries. 2. **Weight and dimensions of the packed unit** — The charge comes from there, and a wrong measurement is corrected late. 3. **Knowing whether it contains anything restricted** — Batteries, aerosols, liquids: the whole procedure changes. 4. **And commercial documentation consistent with itself** — Invoice, packing list and your declaration must say the same. > [!WARNING] > What really holds shipments up is not customs: it is **something inside that nobody declared**. A device with a lithium battery, a spray can inside a box of spares, a sample containing alcohol. Whoever packs it does not think of it as dangerous because they handle it daily, and by air it has its own treatment. Asking «does this contain batteries, liquids or gases?» before packing avoids half the incidents. ## Who you talk to for what **En corto** - The freight forwarder places the cargo and knows what each airline accepts. - The customs agent handles customs, which is a different matter. - And security accreditation is your own process, not something the forwarder solves for you. > [!NOTE] > Which roles exist in the air cargo security chain, what each requires and which goods are restricted are governed by specific aviation rules and vary by country and airline. **Your forwarder or adviser settles that**; here we explain why air freight behaves differently and what is worth resolving beforehand. **Is accreditation worth it?** If you ship often, almost always: it saves on every shipment. **Can I send anything by air?** No, and what you cannot varies. Ask before packing. **Why am I charged more weight than it weighs?** Because volume counts when it is greater; measuring properly avoids surprises. ## Ejemplos **A company air-freights spares and the shipment is grounded by an undeclared aerosol.** - Checks for batteries, liquids or gases before packing and declares them → The next shipment leaves on the planned flight, with no box opened at the airport. **Air documentation is prepared with less margin.** - Checks what is missing when the booking is confirmed → The gap is caught before cut-off. **A document arrives late and the cargo misses the flight.** - Requests early whatever depends on third parties → The wait runs in parallel. **A commodity restriction is discovered at the airport.** - Checks the data sheet before accepting the load → The decision is taken with the document in view. **A client asks about a shipment from months ago.** - Keeps the file with its date → You answer without reconstructing. **Every shipment is prepared from scratch.** - Reuses what repeats per destination → The second shipment costs half. --- --- id: KB-LG-016 url: https://app.codecontract.io/help/logistics/storing-goods-that-are-not-yours idioma: en categoria: sector-logistica subcategoria: almacenamiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-007, KB-CS-020] citadoPor: [KB-LG-020] --- # Storing goods that are not yours _The goods are the client's, the risk while they sit inside may be yours, and what settles a claim is what was recorded on arrival._ **Responde a:** third party warehouse documentation · claim for damage to stored goods · what to record when receiving a client's goods · warehouse keeper liability Storing other people's goods is a trust business decided in two very short moments: when the goods arrive and when they leave. In between come months when nothing happens — until the client opens a box and says it was already like that. ## The two moments that decide everything | Moment | What must be recorded | What it prevents | | --- | --- | --- | | Arrival | Quantity, apparent condition and who delivered | A transport damage ending up as yours | | Arrival, if something looks wrong | Photo and written reservation, that day | Arguing three months later with nothing to show | | While stored | Movements, location and who accessed | «Two pallets are missing and nobody knows» | | Departure | Who it was handed to and in what condition | A claim arriving after the goods have left | > [!IMPORTANT] > The second row is the one that nearly always fails and cannot be reconstructed: **goods that arrive damaged and are accepted without a word become, on paper, goods that were damaged inside**. Nobody will be able to prove otherwise months later, because there is nothing to show. The reservation is made at the time and with a photo, even if the driver is in a hurry and even if the relationship with that client is good: it is precisely what protects that relationship when the problem appears. ## What to hold per client, not per warehouse **En corto** - The storage contract and what it says about damage and limits. - Their insurance and yours, and what each covers while the goods are inside. - Any special instructions given: stacking, temperature, rotation. - And who is authorised to collect on their behalf. > [!WARNING] > That last point causes the most frights and gets the least preparation: **someone turns up to collect with a delivery note and good manners**. With no list of who may collect for each client, the decision falls to whoever is on the loading bay on a Friday afternoon. A short, current list consultable from the bay itself is worth more than any contract clause — because the contract is not at the door and the list is. ## When the claim arrives 1. **Pull the arrival record before replying** — What was noted that day orders the whole conversation. 2. **Check who accessed and when** — Including the client's own people, who sometimes come in. 3. **And answer with facts and dates, not impressions** — «It arrived like this, here is the photo» settles what a long email cannot. > [!NOTE] > What liability you take on as keeper, what limits the contract allows and which insurance is required depend on the type of storage and your country. **Your adviser or broker settles that**; here it is about recording what you will later have to prove. **Must everything arriving be photographed?** Not everything: anything showing a mark, always; and sample the rest. **What if the client accesses their own goods?** Record it the same: it is the only way to know what happened inside. **How long to keep arrival and departure records?** Longer than the relationship: claims arrive late. ## Ejemplos **A warehouse takes in pallets with torn wrap and accepts them silently to keep unloading moving.** - Takes a photo and records a written reservation there and then, even with the lorry waiting → When the client claims three months later, the conversation starts from what was recorded that day. **Third-party goods arrive and their condition is not recorded.** - Captures the condition on entry → The later dispute has something to close on. **The owner takes stock and asks how much of theirs you hold.** - Records movements in and out per owner → You answer with a figure. **Two owners share a location and goods get confused.** - Records what occupies each location → Identity is preserved by location. **A consignment has sat for months without movement.** - Flags what has sat too long → The case is faced before it grows. **The owner disputes a despatch they do not remember requesting.** - Keeps who authorised each despatch → The authorisation has a name and a date. --- --- id: KB-LG-017 url: https://app.codecontract.io/help/logistics/when-goods-change-transport-mode idioma: en categoria: sector-logistica subcategoria: multimodal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-011, KB-LG-007] citadoPor: [KB-LG-018, KB-AL-021, KB-LG-027] --- # When goods change transport mode _Lorry, ship, train, lorry again. Nothing breaks during the journey: it breaks where it changes hands._ **Responde a:** combined transport documentation · damage on a multi-leg shipment · who is liable at transhipment · goods moving by lorry and ship A shipment combining modes looks like a single journey from outside: it leaves your warehouse and reaches its destination. Inside it is three or four separate contracts, each with its own rules, and the goods cross from one to the next in a few minutes that almost nobody documents. ## Where the chain breaks | Point | What happens there | What is nearly always missing | | --- | --- | --- | | Initial loading | It is counted and sealed | Photos of the condition and the seal | | Each transhipment | The responsible party changes | Evidence of condition at that moment | | Intermediate storage | The goods wait for days | Who held them and under what conditions | | Final delivery | It is opened and damage appears | The comparison with how it left | > [!IMPORTANT] > The second row is where claims are lost: **if nobody records the condition at each change of hands, damage can only be attributed to the journey as a whole**. And damage belonging to everyone belongs to nobody: each carrier will say, fairly, that it reached them like that. What makes a leg claimable is a photo and a signature at that leg's handover — thirty seconds that can only be spent then. ## What to settle before it leaves 1. **Who organises the whole and who answers for each leg** — Not always the same, and that difference matters when there is damage. 2. **Which document accompanies each leg** — Each mode has its own and they do not substitute for one another. 3. **How the consignment is identified across all of them** — If the number changes each leg, it cannot be followed. 4. **And where the condition record lives** — Even one photo per leg, in the same file. > [!WARNING] > The costliest confusion is about who answers: **whoever sells you the whole transport is not always who answers for each leg**, and compensation limits change with the mode where the damage happened. When you cannot prove which leg it occurred on, the argument is not about who pays: it is about which regime applies, which can mean very different amounts. Knowing where it happened is often worth more than knowing how. ## When damage shows on opening **En corto** - Photograph before moving anything, with the packaging still as it arrived. - Note the reservation on the delivery document, at the time. - Recover whatever was recorded at each earlier point. - And notify whoever organised the transport promptly: deadlines here are short. > [!NOTE] > Which convention or regime applies to each leg, what limits it carries and within what period you must claim depends on the mode, the route and the contract. **Your freight forwarder or adviser settles that**; here it is about keeping what will show where it happened. **Can I ask for a record at each transhipment?** You can agree it with the organiser; it is not always offered as standard. **Are phone photos any use?** Very much so: what matters is that the identifiable load and the moment are visible. **What if the damage only shows on unpacking?** Photograph and notify anyway: the clock starts at delivery. ## Ejemplos **A company claims for damage on a three-leg shipment and no carrier accepts responsibility.** - Photographs the load at each change of hands and files it all together → The next damage is pinned to one specific leg, which is what makes a claim move. **Damage appears and nobody knows which leg it happened on.** - Records the condition at each change of mode → You can narrow down where it occurred. **Documentation changes with the mode and nobody reviews it.** - Checks what is missing before each handover → The gap is caught before the delay. **One leg is run by an operator with their own system.** - Collects and stores what they provide → Your own archive stays complete. **A client asks where their shipment is.** - Checks the file with the recorded handovers → You answer with what exists rather than with a phone call. **Days pass with no news and nobody raises the alarm.** - Warns when a shipment has gone too long without movement → Silence stops being mistaken for normality. --- --- id: KB-LG-018 url: https://app.codecontract.io/help/logistics/dangerous-goods-the-papers-that-travel idioma: en categoria: sector-logistica subcategoria: terrestre audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-030, KB-LG-017, KB-LG-003, KB-LG-015] citadoPor: [KB-LG-007] --- # Dangerous goods: the papers that travel _Here the paperwork does not accompany the shipment: it is part of it. Missing, the lorry does not leave — or worse, it does._ **Responde a:** documentation to transport dangerous goods · what a dangerous goods note contains · who is liable if a shipment is badly documented · safety data sheet and transport In ordinary transport, a misplaced paper gets fixed over the phone. With dangerous goods it does not: the document is what tells the driver what is behind them, the fire brigade what they will find, and the receiving warehouse what must not be stored beside it. That is why paperwork here has a different status. ## Who answers for what — the most confused part | Role | What is theirs | What usually fails | | --- | --- | --- | | The consignor | Classifying properly and passing on the information | Classifying «as always» without checking whether the product changed | | The carrier | Carrying the documentation and a compliant vehicle | Leaving with the previous shipment's paperwork | | The loader | That what is loaded matches what is declared | Loading by eye something done every day | | The consignee | Checking before unloading | Unloading first and looking afterwards | > [!IMPORTANT] > What needs unlearning is the idea that this is the carrier's responsibility: **classifying what is shipped belongs to whoever ships it**, and it is not delegated by loading it onto a lorry. The carrier answers for carrying it properly; you answer for the paper saying what is actually inside. When those two diverge, the problem is not a fine: it is that whoever has to intervene on a roadside will act on false information. ## The documentary chain, in order 1. **The product's current safety data sheet** — Current: if the maker revised it, your three-year-old copy no longer describes the same thing. 2. **The classification and labelling that follow from it** — Not from habit or from what the last delivery note said. 3. **The transport document with what it requires** — And a copy filed on your side, not only the one travelling with the lorry. 4. **And the instructions and training of whoever handles it** — Including the loader, not only the driver. > [!WARNING] > The case that causes most grief looks innocent: **the product's formula changes and nobody revisits the safety data sheet**. The supplier updates it on their website, you keep using the PDF they sent when you started, and since then every shipment has been classified on old data. There is no visible mistake by anyone, and yet each lorry leaves with a description that does not match. Requesting the sheet with its date and reviewing it at least yearly closes this door entirely. ## What to file even when nobody asks **En corto** - A copy of each shipment's transport document, with its date. - The version of the safety data sheet used to classify THAT shipment. - The training of whoever loaded and whoever classified, with validity dates. - And incidents, however small: a documented one-litre spill is worth more than ten undocumented ones. > [!NOTE] > Which goods are regulated, how they are classified, exactly which documents each transport mode requires and what training each person needs is set by the dangerous-goods transport rules and by your safety adviser. **Your adviser settles that**; here we cover the documentary failure that depends not on the rules but on the filing. **Is this the carrier's responsibility?** Carrying it properly is theirs. That the declaration matches the contents is the consignor's. **How often do I review safety data sheets?** At least yearly, and whenever the supplier reports a formula change. **Do I keep a copy of the transport document?** Yes. It is what lets you reconstruct a shipment months later. ## Ejemplos **A supplier changes a product's formula and you keep classifying from a three-year-old safety data sheet.** - Requests the sheet with its date and reviews it at least yearly → Shipments stop leaving described with data that no longer matches. **A lorry departs carrying the previous shipment's transport document.** - Checks at loading that the declaration matches the load, signed by the loader → The error is caught on the bay, the only place where it is still cheap. **Months later a shipment must be reconstructed and the only copy travelled with the lorry.** - Files a copy of the transport document and the data sheet version used for each shipment → The shipment is reconstructed with what existed that day, not with what exists today. **The paper travels with the driver and gets lost.** - Also carries it accessible from a phone → A lost paper stops halting the job. **Loading happens without checking the goods' data sheet.** - Checks the sheet before accepting → The decision is taken with the document in view. **A check asks about a job from months ago.** - Keeps a file per job → You answer from the record. --- --- id: KB-LG-019 url: https://app.codecontract.io/help/logistics/the-intermediary-who-never-touches-the-goods idioma: en categoria: sector-logistica subcategoria: transitarios audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-013, KB-NO-022] citadoPor: [KB-LG-023] --- # The intermediary who never touches the goods _You neither load nor store it, and yet all the paperwork passes through you. That is where liability sits._ **Responde a:** freight forwarder documentation liability · im a transport intermediary what papers do i keep · freight broker obligations · liability of whoever arranges the transport You arrange the transport, choose the carrier, handle the documents and never see the goods. It is easy to think that whoever does not touch does not answer — and in practice the opposite holds: **all the information passes through you, so you are the only point where a mismatch can be spotted**. **Transport intermediary** — Whoever arranges carriage without performing it: contracts the carrier, passes on instructions and documents, and is often the only party seeing the whole operation end to end. ## What is yours even though you never touch the load | What | Why it is yours | | --- | --- | | Choosing the carrier | You chose, with everything that entails | | Passing on complete instructions | What you do not pass on, the driver will not know | | Keeping each operation's documentation | You are the only point where it exists whole | | **Spotting what does not add up** | **Nobody else sees both ends at once** | > [!IMPORTANT] > **The fourth row is what sets you apart and what is most ignored: you are the only ones seeing origin and destination on the same screen.** The shipper knows their part, the carrier theirs, the consignee the last. If a goods description does not match the destination, if a document is missing, or if the agreed temperature does not fit what was contracted, the only place that can be seen before the lorry leaves is your desk. ## What to file per operation 1. **Who you contracted and on what terms** — Including their authorisation or licence where the carriage requires it. 2. **The instructions you passed on, verbatim** — If something is lost en route, it is what places you. 3. **The operation's documents in full** — Not only those you were asked for: the whole chain's. 4. **And incidents, including small ones** — A pattern with one carrier only shows if they were recorded. > [!WARNING] > The specific risk of this position: **passing on a half instruction**. A «keep it chilled» with no exact temperature, a «delicate goods» that does not say what, a «deliver on site» with no site hours. The driver will do what they understood, and what they understood depends on what reached them — which came from you. The complete instruction, written and kept, is the invisible part of the job and the only one examined when something goes wrong. > [!NOTE] > Which responsibilities an intermediary assumes, what licences they need and what documentation they must keep depends on the transport mode, the country and each contract. **Your adviser settles that**; here we cover the part independent of legal form: you are the only point that sees the whole operation. **If I never touch the goods, am I liable?** For the choice, the instructions and the documentation, yes. **Do I have to check the carrier?** At minimum that they are licensed for that carriage. And keep proof. **How long do I keep the documentation?** Longer than the operation: claims arrive much later. ## Ejemplos **«Keep it chilled» is passed on with no temperature and the lorry arrives at another.** - Passes the full instruction in writing and files it with the operation → What was asked for is clear, and the driver knows what they had to do. **A claim arrives a year later and that operation's documentation is incomplete.** - Files every document per operation, not only those requested → The claim is answered with the file rather than with recollections. **A carrier accumulates small incidents nobody has ever recorded.** - Records minor incidents too, with dates → The pattern becomes visible and staying with them is decided on data. **A job is placed verbally and later the versions differ.** - Asks for written confirmation and keeps it → What was agreed stops depending on two memories. **The client complains about something the carrier did.** - Keeps what was agreed with each party → Each party answers for their own, with the trail in view. **Nobody knows whether the carrier is current.** - Checks their file before placing a load → The gap shows before the job. --- --- id: KB-LG-020 url: https://app.codecontract.io/help/logistics/the-warehouse-storing-for-several-owners idioma: en categoria: sector-logistica subcategoria: almacenamiento audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-016, KB-AL-021, KB-LG-027] citadoPor: [KB-LG-021] --- # The warehouse storing for several owners _You hold goods that are not yours, for several clients at once. What protects you is knowing at all times what belongs to whom._ **Responde a:** logistics warehouse third party goods · what a logistics operator is liable for · stock control for several clients · documentation for goods on deposit On your racking there are goods belonging to six different companies. None is yours and you answer for all of it while it sits there. It is a comfortable position commercially and an uncomfortable one documentarily: **the risk is not in what you do, it is in what you cannot show**. ## The four questions you will be asked | Question | What answers it | | --- | --- | | What came in, when and from whom? | The intake record, with condition on arrival | | Under what conditions was it stored? | The warehouse records for that period | | What went out, when and on whose order? | The despatch record and who authorised it | | **How do you know this belongs to that client?** | **Separation and identification — where it fails** | > [!IMPORTANT] > **Receiving without checking is accepting what arrived as it arrived.** It is the same loading-bay rule as in any sector, and here it weighs double because the goods are not yours: if they come in damaged or short and you sign without reservation, the damage moves inside your custody period. Recording condition on arrival —even one line and a photo— is the difference between holding goods and answering for what someone else broke. ## What to agree with each client 1. **Who may order a despatch and how that is verified** — This is where serious problems enter, not the stocktake. 2. **What is checked on receipt and what is recorded** — Quantity, condition, temperature where relevant, accompanying paperwork. 3. **What happens to goods arriving in poor condition** — Accept under reservation, reject or isolate. Decided beforehand. 4. **And what happens if a client stops paying or vanishes** — Awkward to agree and worse to resolve with nothing written. > [!WARNING] > Big trouble does not enter through the warehouse: **it enters through the despatch order**. A phone call, an email from a lookalike address, someone claiming to be from the client. The goods leave, and showing afterwards that the order looked legitimate is very hard with no procedure in place. Who may request a despatch, through which channel and how it is verified must be agreed in writing with each client — not decided by whoever is in the office that afternoon. > [!NOTE] > What duties a bailee assumes, what they answer for regarding others' goods and what documentation they must keep depends on the contract and on the rules applying to the activity and product type. **Your adviser settles that**; here we cover what in practice decides whether you can show you complied. **Am I liable for my clients' goods?** While in your custody, on the contract's terms. Hence the arrival condition. **Can I release goods on a phone call?** That is exactly where problems enter. Agree the procedure. **What if a client vanishes?** With nothing written, a long problem. Agree it at the outset. ## Ejemplos **A damaged pallet comes in and the receipt is signed with nothing recorded.** - Records condition on arrival, with a photo, and accepts under reservation → The damage does not move inside the custody period. **Goods are released on a phone call from someone claiming to be the client.** - Agrees in writing who may order despatches and how it is verified → Releases stop depending on the judgement of whoever answers the phone. **A client claims product was short and there is no record of exactly what came in.** - Logs intakes with quantity, condition and accompanying paperwork → The claim is settled with the record instead of two versions. **Two owners share racking and goods get confused.** - Records what occupies each location → Identity is preserved by location. **An owner asks how much of theirs you hold.** - Records movements in and out per owner → You answer with a figure. **One owner's goods are despatched to another by mistake.** - Checks the owner before every despatch → The error is avoided at the bay. --- --- id: KB-LG-021 url: https://app.codecontract.io/help/logistics/receiving-on-someone-elses-behalf idioma: en categoria: sector-logistica subcategoria: paqueteria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-012, KB-LG-020] citadoPor: [KB-LG-026] --- # Receiving on someone else's behalf _Someone at reception signs for something they never ordered. That signature counts, and from then on the clock runs for their company._ **Responde a:** who can sign for a delivery at a company · i signed a note that wasnt mine · receiving goods without checking · signing for a delivery on behalf of the company A courier arrives at half past nine. Whoever happens to be on reception signs the note without looking and leaves the parcel in a corner. That signature is, to all intents, the company's — and from that moment the clock runs for saying something arrived wrong. ## What signing does, even if nobody thinks about it **En corto** - It accepts that it arrived, starting the clock for claims. - It accepts that it arrived **as it arrived**, unless noted otherwise. - It accepts on the company's behalf, even if the signer has no idea what it is. - And often it accepts without anyone telling the department that was waiting. > [!IMPORTANT] > **Signing «received in good order» without opening anything is what turns transport damage into your problem.** You do not need to inspect the contents on the bay, but you do need to look at the outside: a knocked carton, a broken pallet wrap, an opened seal. Writing «package damaged» on the note before signing takes five seconds and is the only sentence that lets you claim later. ## The minimum, and it is organisational rather than logistical 1. **Whoever signs knows what to look at** — External condition, number of packages, and that your company is the addressee. 2. **Anything that does not fit is written down before signing** — After the signature, that same sentence no longer does the same work. 3. **Whoever was waiting gets told** — The parcel in a corner is cause number one of «this never arrived». 4. **And the note is kept, not binned with the packaging** — It is the delivery evidence, and it ends up in the bin surprisingly often. > [!WARNING] > One case is worth settling in advance at any reception desk: **the courier is in a hurry and pushes for a signature without a look**. It is not bad faith, it is their route. But the hurry is theirs and the consequences are yours. A one-line instruction to whoever is on reception —«if the package is damaged, note it before signing, even if the courier is waiting»— resolves ninety per cent of the claims that later cannot be sustained. **Can anyone sign?** In practice yes, which is why they should know what to look at. **What if the parcel was not for us?** Do not sign it. Hand it straight back. **I signed and it was damaged — can I claim?** Much harder. Report it immediately and in writing. ## Ejemplos **A visibly knocked package is signed for with nothing noted, and a claim follows.** - Writes «package damaged» on the note before signing → The claim stands because the arrival condition is on record. **The parcel sits in a corner and whoever was waiting treats it as never delivered.** - Tells whoever was waiting as soon as it is received → Material stops being simultaneously received and hunted for. **The delivery note is binned with the packaging and no proof of delivery remains.** - Files the note with the order → The delivery can be evidenced months later. **Whoever is on reception signs without looking at what they sign.** - Records who received each delivery → Half the disputes disappear. **Something the company never ordered is signed for.** - Checks the recipient before accepting → What does not belong is not accepted. **A damaged delivery is accepted with no record.** - Notes the incident at the moment → Acceptance does not close the door to claiming. --- --- id: KB-LG-022 url: https://app.codecontract.io/help/logistics/the-importer-answering-for-data-they-did-not-produce idioma: en categoria: sector-logistica subcategoria: aduanas audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-002, KB-IU-020] citadoPor: [KB-LG-023, KB-LG-024] --- # The importer answering for data they did not produce _You declare what someone eight thousand kilometres away emails you. If the data is wrong, the name answering for it is yours._ **Responde a:** importer responsibility for the declaration · supplier sending wrong invoice data · which documents to keep for each import · audit of imports from three years ago Your goods cross a border carrying three facts: what they are, what they are worth, where they come from. **You produce none of those three** — they reach you on an invoice and a packing list written by the supplier, often in a language native to neither of you. And yet the declaration carries your name. This is the position that worst reflects the real split between who knows and who answers. ## Where each fact comes from and who can check it | The fact | Who states it | Who can check it | | --- | --- | --- | | What the goods are | The supplier | You, if you know the product | | What they are worth | The supplier's invoice | You, against what you paid | | Where they come from | The supplier | **Almost nobody, and it is the most reviewed** | | **How it is classified** | **Whoever declares** | **You, and it is your decision** | > [!IMPORTANT] > **A review does not arrive on clearance day: it arrives years later and looks backwards.** That characteristic defines this position and decides how to file. At clearance everything moves fast because a lorry or a container is waiting; the real checking happens once the supplier has changed sales contact, the forwarder has changed systems and you have changed the person in charge. All that remains is what was kept. ## What to keep per operation, not per supplier 1. **The invoice and packing list exactly as they arrived** — The originals, not the version someone amended by hand afterwards. 2. **Whatever evidences the origin** — It is the most reviewed fact and the least reconstructable. 3. **What was declared and on what basis** — Especially where it was a judgement and not an obvious call. 4. **And the trail of what was asked of the supplier** — Having asked, and what came back, is worth a great deal on review day. > [!WARNING] > The costliest mistake here is **correcting without leaving a trail**. An invoice arrives with an odd figure, the supplier is asked to reissue, the good one is filed and the first is binned. Months later nobody can explain why two versions are circulating, nor show that the correction was a correction and not a convenience. Keeping both, with their dates and the email in between, turns an awkward finding into a story that holds together. > [!NOTE] > What responsibilities fall on whoever is named as importer, what documentation must be retained, for how many years and what happens if a declared fact proves incorrect **depends on the country and the applicable regime, and is settled by your adviser or customs representative**. Here we cover what decides whether you can answer: what you keep per operation and whether you can find it years later. **Is what my forwarder keeps enough?** While you work with them. The operation is yours and so should the archive be. **How long must it be kept?** Longer than it seems, and your adviser settles it. Keep with reviews in mind, not clearance. **What if the supplier sends a wrong figure?** Ask in writing and keep the reply. That trail is half the defence. ## Ejemplos **A review asks about imports from three years ago.** - Keeps each operation with its documents and dates → It is answered from the archive, not the forwarder's memory. **The supplier reissues an invoice and the first one disappears.** - Keeps both versions with their dates instead of replacing them → The correction can be explained rather than defended. **One import's documents sit across three email threads.** - Gathers everything for an operation in a single file → What is there and what is missing is visible at once. **The document evidencing origin never arrived and nobody noticed.** - Flags what is missing before the operation is treated as closed → The gap is caught while the supplier still replies. **You change forwarder and the history stays in their system.** - Keeps the importer's archive independent of the provider → Changing partner does not take the previous years with it. **Nobody remembers what the supplier was asked about an odd figure.** - Keeps the request and the reply alongside the operation → Having asked is evidenced rather than recounted. --- --- id: KB-LG-023 url: https://app.codecontract.io/help/logistics/declaring-on-someone-elses-behalf idioma: en categoria: sector-logistica subcategoria: transitarios audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-022, KB-LG-019] citadoPor: [KB-LG-013] --- # Declaring on someone else's behalf _You file what you are told and you are the one who signs. Your entire defence is being able to show who told you what, and when._ **Responde a:** customs representative liability · declaring with data provided by the client · how to protect myself if the client gives wrong information · written client instructions customs Your job is turning what a client sends you into something the authorities accept. **You know procedure and you do not know their product**: you are told what it is, what it is worth and where it comes from, and you file it. It is a service position carrying an exposure that is not always priced as one, and all of it turns on a single point: **being able to show what you were told**. ## The three sources of a problem, and only one is yours | Where it comes from | Example | What prevents it | | --- | --- | --- | | The client informed wrongly | A wrong value or origin | Holding in writing what they said | | The client did not inform | A document was missing and it went anyway | Recording what was asked for | | You applied it wrongly | A debatable judgement of your own | The reasoning, written and dated | | **Nobody knows what happened** | **No trail of anything** | **The worst case and the commonest** | > [!IMPORTANT] > **A verbal instruction does not exist.** That is the whole sentence for this position. The client who phones in a hurry to say it is worth less, that the origin is different, or to clear it and they will send the paper later, is making a decision with your name underneath. Asking for it in writing is not mistrust or bureaucracy: it is the only thing separating who informed from who filed when someone asks two years later. ## What must be showable for each file 1. **What the client sent you and when** — With the date and the document exactly as it arrived. 2. **What you asked for and what came back** — Including the requests they never answered. 3. **What was finally filed** — And if it departed from what you were told, why. 4. **And who authorised the doubtful call** — By name. «The client said» is not a name. > [!WARNING] > The scenario to avoid above all others: **clearing without a document on the promise that it arrives tomorrow**. It is a reasonable request, made by a client who matters to you, and it almost always ends well. The problem is the case where it does not: then there is a completed clearance, a document that does not exist and a conversation that only happened by phone. If you are going to take that risk —sometimes the business calls for it— have it in writing who asked and on what undertaking. > [!NOTE] > What liability a representative assumes depending on the form of representation, what they may require of their client and how far their duty to check extends **is determined by the applicable rules and the contract, and settled by your adviser**. Here we cover the operational part: how to leave a trail of what was received and requested without slowing clearance. **Can I refuse to declare something that does not add up?** Your contract and the rules decide that. What you can always do is put it in writing. **Does an email count as an instruction?** It is infinitely better than a phone call, and it is what exists in practice. **Should I keep what I asked for and never received?** Above all that. It is what proves it was asked for. ## Ejemplos **The client gives an instruction by phone and later remembers it differently.** - Asks for written confirmation and files it with the case → What was agreed stops depending on two memories. **Clearance goes ahead on the promise of a document that never arrives.** - Records what was asked for, when, and what came back → The broken undertaking is documented. **Two years on a file is queried and the context is missing.** - Keeps what was received, requested and filed together → The file explains itself. **Each operator keeps their emails in their own inbox.** - Gathers the file's documentation in a shared place → The answer does not depend on who is in that day. **Chasing the client for a document takes half a day.** - Chases automatically until it arrives → The chase stops competing with the day's work. **It is unclear who authorised a debatable decision.** - Records who asked for what and when → The authorisation has a name and a date. --- --- id: KB-LG-024 url: https://app.codecontract.io/help/logistics/holding-the-goods-while-the-paperwork-is-missing idioma: en categoria: sector-logistica subcategoria: terminales audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-022, KB-LG-009] citadoPor: [KB-LG-027] --- # Holding the goods while the paperwork is missing _The goods are in your hands, the problem is not yours, and the cost starts running from day one._ **Responde a:** goods held for missing documentation · who pays storage for a stuck container · warehouse liability for third-party goods · how to evidence days in storage A terminal, a bonded store or a transit warehouse hold a very particular position: **you physically hold something that is not yours, over a problem you did not cause, and every passing day generates a cost somebody will have to pay**. You cannot solve the problem —someone else holds the papers— and you cannot walk away, because the goods are there. ## What accumulates while something sits | What runs | Who it hits | What evidences it later | | --- | --- | --- | | Days in storage | The owner of the goods | The in and out record | | The space occupied | You | The same, which is why it matters | | The condition of the goods | Both | What was checked on receipt | | **The argument over who pays** | **Whoever documented it worst** | **The trail of notices sent** | > [!IMPORTANT] > **What decides this position is not custody, it is notification.** Storing things properly you already know how to do. What gets argued months later is whether the owner knew in time that their goods were stuck, how many times they were told, and what they said. A store that notifies and records it turns a disputed invoice into an explained one; one that merely stores holds the goods and does not hold the conversation. ## What to record from day one 1. **What came in, when and in what condition** — With what could be checked and what could not, said as such. 2. **What is missing for it to leave** — Written so the owner understands without phoning. 3. **Who was notified and when** — Every notice, not just the first. 4. **And what came back, silence included** — Documented silence is also an answer. > [!WARNING] > The point that causes most trouble: **goods that stay and lose their contact**. The importer disappears, the forwarder says they no longer handle that client, and the cost keeps running against someone who does not answer. The later it is spotted, the worse: at one month it is an awkward call, at a year it is a hard decision about something taking up space. Having what has been sitting too long in plain view is what stops you reaching the second case. > [!NOTE] > What duties of custody, information and retention you carry over other people's goods, what time limits apply and what may be done with what nobody claims **depends on the regime the goods are under and on the contract, and is settled by your adviser**. Here we cover the operational part: what to record, who to notify and how to evidence having done it. **Do I need to notify more than once?** In practice it is what holds the invoice up afterwards. Record every notice. **What do I do if nobody answers?** Document it and escalate early. The problem grows with time, it does not settle. **Is the entry record enough?** It is the minimum. What gets argued is what happened after entry. ## Ejemplos **A container has been sitting for weeks and its owner says they did not know.** - Records every notice sent and its date → The storage invoice is explained by the trail. **Nobody knows exactly what is missing for a consignment to leave.** - Shows which document is missing and whose it is → The owner can act without a phone call first. **There is a dispute about the condition the goods arrived in.** - Keeps what was checked on entry, with the date → The dispute closes on the record. **A consignment has sat for a year and nobody answers any more.** - Flags what has gone too long without movement → The case is faced at one month rather than one year. **Notices go out from personal email accounts and no copy remains.** - Sends and keeps communications in the file → Each notice is demonstrable rather than remembered. **The owner changes forwarder and nobody knows who to write to.** - Records who the contact is for each consignment → The notice reaches somebody who exists. --- --- id: KB-LG-025 url: https://app.codecontract.io/help/logistics/the-last-mile-is-done-by-another-company idioma: en categoria: sector-logistica subcategoria: ultimamilla audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-012, KB-LG-008] citadoPor: [KB-LG-026] --- # The last mile is done by another company _Whoever rings the doorbell does not work for you, and the customer thinks they do. Their way of recording things becomes yours._ **Responde a:** proof of delivery from a subcontracted courier · customer says the parcel never arrived · controlling what my last mile does · claims about deliveries made by someone else The order is yours, the brand is yours and the complaint will come to you. **Whoever rings the doorbell is not.** Between your decision to ship and the customer's door there are one or more other companies, each with their own way of working, their own app and their own view of what deserves a photo. And when the customer says it never arrived, all you can show is whatever that courier chose to record. ## Who sees what in a subcontracted delivery | Who | What they see | What they can prove | | --- | --- | --- | | The customer | Your brand | That they paid | | You | A status in a system | Whatever is passed to you | | The partner | The whole delivery | **Whatever they chose to record** | | **The courier** | **The door** | **Whatever they were asked to record** | > [!IMPORTANT] > **What can be proved about a delivery is decided in the contract with the partner, not in the complaint.** It is the only real lever in this position. If at contracting nobody defined what counts as acceptable proof —what is captured, when, and how it reaches you— then at complaint time you will be asking a favour, and that favour will arrive late, incomplete, or not at all. ## What to settle before the first round 1. **What is captured on each delivery** — And what happens when nobody is in: that is the case that generates complaints. 2. **How that reaches your system** — If it lives only in the partner's app, it is not yours. 3. **How long it is retained** — Complaints do not arrive the same day. 4. **And what happens if the partner subcontracts** — It usually does. Decide in advance whether it is allowed and on what terms. > [!WARNING] > What sinks this position is not the lost delivery: **it is the delivery that did happen and cannot be shown**. The customer complains in good faith, the courier remembers leaving it, and there is nothing to show but a «delivered» status in a system the customer does not regard as proof of anything. You end up refunding and looking bad at once, the worst of both worlds, and it happens for want of two fields defined when the agreement was signed. > [!NOTE] > What constitutes valid proof of delivery, what liability you retain over a partner's actions and what may be required of them **depends on the contract and the applicable rules, and is settled by your adviser**. Here we cover the operational part: how to ensure the evidence reaches your archive rather than staying in someone else's. **Can I require photos on every delivery?** You can agree it at contracting. Afterwards it is a request, not a condition. **Is the «delivered» status in their system enough?** To operate, yes; against a complaining customer, almost never. **What if the partner changes app?** Which is why the evidence must end up in your archive, not only theirs. ## Ejemplos **A customer complains about a delivery and there is nothing to show.** - Keeps the evidence of each delivery in your own archive → You answer with proof rather than a status. **The evidence lives only in the partner's app.** - Collects and stores what third parties provide → Proof stops depending on someone else's system. **The partner subcontracts and an unknown courier turns up.** - Records which companies are authorised on each route → The delivery chain is known. **The complaint arrives months after the delivery.** - Keeps evidence beyond the closing of the order → The answer does not depend on a third party's retention. **Each partner sends evidence in a different format.** - Requests specific documents to a single destination → What is received is comparable across partners. **Nobody knows which partner is current on their documentation.** - Shows each partner's status → You contract knowingly rather than reviewing afterwards. --- --- id: KB-LG-026 url: https://app.codecontract.io/help/logistics/delivering-to-a-hundred-small-points idioma: en categoria: sector-logistica subcategoria: distribucion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-025, KB-AL-012, KB-LG-021] citadoPor: [KB-CS-019] --- # Delivering to a hundred small points _A hundred stops a day and at each one whoever is there signs. None matters until one does._ **Responde a:** who can sign for a delivery at a shop · multi-drop delivery proof · customer says not everything was delivered · delivery notes getting lost Your driver makes a hundred stops and delivers little at each: a few boxes, a pallet, a small order. **At none of them is there a loading bay, a goods-in supervisor or any time**: whoever is behind the counter signs, often without looking at what they sign, and sometimes without being the person who should. Multiplied by a hundred stops and two hundred days, that detail becomes the operation's biggest source of disputes. ## The typical disputes, and which are avoidable | The dispute | How often | What avoids it | | --- | --- | --- | | «Not everything arrived» | Constant | Recording what was left, not just that it was | | «I did not sign that» | Common | Knowing who signed | | «It arrived damaged» | Common | A photo at delivery | | **«No delivery on record»** | **Rare and costly** | **A delivery note not dependent on paper** | > [!IMPORTANT] > **The cost in this position is not the difficult stop: it is the sum of a hundred trivial ones.** Each generates a slip, each slip can be lost, and each loss is resolved with a ten-minute call nobody counts. The annual bill for those calls is always larger than capturing the delivery at the moment would cost — but since it is paid in ten-minute pieces, it never shows up anywhere as a problem. ## What changes a hundred-stop round 1. **Evidence captured at the stop** — If it depends on returning to base with paper, paper gets lost. 2. **Recording who received, not only that it was received** — It is half the disputes, and it costs one field. 3. **A photo when the delivery is not clean** — Not on all hundred; on the ones the driver already knows will be trouble. 4. **And it reaching the customer's file on its own** — Without anyone transcribing anything in the afternoon. > [!WARNING] > The stop to settle in advance is **the one where nobody authorised is present**. The driver has ninety-nine more stops, the customer wants their goods, and the convenient way out —leave it and let whoever is there sign— is the one that creates next month's complaint. It does not need a complicated policy: it needs the driver to know what to do, and whatever they decide to be on record. > [!NOTE] > What weight a receipt signature carries, who may validly receive on a company's behalf and what time limits apply to claims **depends on the contract and the applicable rules, and is settled by your adviser**. Here we cover the operational part: how to capture at the stop what will later decide a dispute. **Does an on-screen signature count?** In practice it is widely used. What weighs most is knowing who signed. **Must every delivery be photographed?** No. The ones the driver knows may cause trouble, yes. **What if nobody authorised is there?** Give the driver a rule, and record whatever they decide. ## Ejemplos **A customer says goods were missing from a delivery a month ago.** - Records exactly what was delivered at each stop → The dispute closes on the stop's record. **The paper delivery note is lost before reaching the office.** - Captures the delivery at the moment from a phone → The document stops travelling in the van. **Nobody knows who signed for a particular receipt.** - Stores who received alongside the delivery → Half the disputes disappear. **A delivery arrives damaged and its condition is not recorded.** - Allows attaching photos at the stop itself → Condition is documented as it happens. **Incidents are transcribed in the afternoon and detail is lost.** - Records the incident where and when it happens → What is recorded is what the driver saw. **Each clarification call costs ten minutes and there are many.** - Makes the evidence available to whoever handles the customer → The clarification is resolved without calling the round. --- --- id: KB-LG-027 url: https://app.codecontract.io/help/logistics/the-leg-that-travels-in-someone-elses-hands idioma: en categoria: sector-logistica subcategoria: ferroviario audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LG-017, KB-LG-024] citadoPor: [KB-LG-020] --- # The leg that travels in someone else's hands _For days the goods are not in your system but in an operator's, with their own calendar and their own records._ **Responde a:** tracking goods on a rail leg · no visibility over one leg of the transport · documentation between operator and end customer · who answers on a combined transport Part of the journey is done neither by you nor by a partner you chose for their service: it is done by an operator with their own infrastructure, timetables fixed in advance and systems nothing like yours. **During that leg the goods exist in somebody else's records**, and your customer still asks you where their shipment is. ## What changes versus a leg you control | What is at stake | Your own leg | An operator's leg | | --- | --- | --- | | When it departs | You decide | It is fixed | | Where it is now | You know | They know | | What happened en route | You record it | **They record it, their way** | | **Who answers to the customer** | **You** | **Still you** | > [!IMPORTANT] > **With a leg you do not control, information stops being a by-product of the operation and becomes something that must be agreed explicitly.** On your own legs the data appears by itself because your people generate it. On this one nothing appears that was not agreed: what is communicated, when, in what format, and what happens when something departs from plan. Whatever is not in that agreement, you will not have on the day you need it. ## What to settle at the handover points 1. **What is recorded on handing over to the operator** — Condition, quantity and time: it is the snapshot separating you from whatever follows. 2. **What is recorded on collecting it** — The same snapshot, so the two can be compared. 3. **What is communicated in between** — And how often. Silence does not mean everything is fine. 4. **And what documentation travels with the goods** — Especially if it crosses borders or changes regime. > [!WARNING] > The place where money is lost is **the handover, not the journey**. A shipment that leaves fine and arrives damaged has passed through at least two hands, and the argument over which of the two is settled —or not— by what was recorded at each handover. Without those records each party reasonably maintains it was fine when they let go, and the bill ends up with whoever documented worst, who is not necessarily whoever broke it. > [!NOTE] > What documentation must accompany goods in each transport mode, what liability regime applies to each leg and how a combined transport is structured **depends on the applicable conventions and contracts, and is settled by your adviser**. Here we cover the operational part: how to document handovers and not depend on a third party's system. **Can I require real-time tracking?** You can agree it. What is not agreed at contracting does not arrive later. **What do I do if there is no news for days?** Give the absence of news a threshold that raises itself. **Is the transport document enough?** To operate, yes. To argue over damage, you need both handover snapshots. ## Ejemplos **Goods arrive damaged and nobody knows on which leg it happened.** - Records condition at each handover with date and time → The two snapshots narrow down where it occurred. **Days pass with no news and nobody raises the alarm.** - Warns when a shipment has gone too long without movement → Silence stops being mistaken for normality. **The customer asks and the operator has to be phoned.** - Gathers what is known about the shipment in one file → You answer with what exists without waiting on a third party. **The leg's documentation lives only in the operator's system.** - Collects and keeps what the third party provides → Your own archive does not depend on another system. **Each operator communicates differently.** - Requests the information in an agreed format → What is received is comparable across operators. **Months later a damage claim arises and the departure record is missing.** - Keeps handovers beyond the closing of the shipment → The late claim has something to answer with. --- --- id: KB-CS-008 url: https://app.codecontract.io/help/logistics/haulier-documentation idioma: en categoria: sector-logistica subcategoria: terrestre audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-004, KB-CF-008] citadoPor: [KB-NO-003, KB-CS-019, KB-CS-020, KB-LG-001, KB-LG-007, KB-LG-008] --- # Haulier documentation _Making sure today's lorry belongs to a company with everything in order._ **Responde a:** subcontracted haulier documentation · external fleet document control · haulier cargo insurance · transport documentation control In transport, paperwork expires fast and the fleet changes by itself: today a lorry arrives from a subcontractor that did not exist three months ago. Control has to be per vehicle and per driver, not a folder per company reviewed annually. **En corto** - Nearly everything expires: operator licence, roadworthiness, insurance, dangerous goods certification. - A driver without current paperwork should not be loading. - Status has to be visible at the loading bay, not in the office. ## What gets controlled | Level | Documents | Expires | | --- | --- | --- | | Company | Operator licence, liability insurance, tax clearance | Yes, all of them | | Vehicle | Roadworthiness test, insurance, special authorisations | Yes | | Driver | Licence, professional competence, dangerous goods where applicable | Yes | > [!IMPORTANT] > A vehicle with a lapsed roadworthiness test or a driver without current professional competence is not a paperwork problem: it is your liability if you gave them a load. It is the sector where document control has the most direct consequences. ## What changes at the bay Letting whoever receives check on a phone whether that registration and that driver are in order turns an office decision into a gate decision — which is where it is actually made. > [!NOTE] > With subcontracted fleets, setting expiry warnings 30 days out is what avoids the classic lorry arriving with a roadworthiness test that lapsed last week. **What about one-off hauliers?** A quick case with the essentials: insurance and licence. **Can it be tracked by registration?** Yes, the vehicle is a participant with its own documents. **Is it what a transport inspection wants?** It is exactly what you show them. ## Ejemplos **A logistics operator works with 35 subcontracted hauliers.** - One case per haulier, with their vehicles and drivers - Expiries marked 30 days out → The bay checks before loading and lorries turned away at the gate over paperwork disappear. **A carrier goes out with something expired.** - Checks their status before assigning a load → The job does not go out with a gap. **Each carrier sends their material whenever they remember.** - Requests and chases automatically → Follow-up occupies nobody. **A client asks for the documentation of whoever delivered.** - Checks that carrier's file → It is provided without searching. **A new partner joins on the same day.** - Checks what they are missing before assigning a load → Onboarding is resolved before departure. **Documentation expires mid-season.** - Warns about expiries in advance → Renewals happen before the peak. --- --- id: KB-CS-022 url: https://app.codecontract.io/help/legal/tax-and-payroll-advisers idioma: en categoria: sector-legal subcategoria: despachos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-009, KB-GL-013] citadoPor: [KB-LE-001, KB-LE-002, KB-LE-006, KB-LE-014] --- # Tax and payroll advisers _Hundreds of clients sending the same things every month, and always late._ **Responde a:** request documents from accountancy clients · collect payslips and invoices monthly · clients who send documents late · accountancy client document management An accountancy firm's problem is not complexity: it is that two hundred clients have to send the same things before the 15th, and thirty do not. Chasing those thirty consumes more time than doing the other two hundred's work. ## The three modules | What | Module | Rhythm | | --- | --- | --- | | Each client's monthly or quarterly documents | Trackline | Recurring, with automatic reminders | | Engagement letter and authority to represent | Consigne | At client onboarding | | What was filed on time | SmartCheck | On filing, where it may be disputed later | > [!IMPORTANT] > An engagement letter signed before starting avoids the sector's commonest scope dispute: what the retainer covered and what it did not. Signing it is faster than arguing about it on the first extra invoice. ## Frameworks cited Client identification duties under anti-money-laundering rules, data protection when handling third parties' information, and — depending on the service — authority to act before the authorities. Specific identification and retention requirements depend on your activity and professional body; confirm them with your adviser. > [!WARNING] > A firm holds documents for clients who compete with each other, and often personal data about their staff. One team per client is not internal tidiness: it is what stops an account manager seeing a competitor's material. ## What gives back the most time Recurrence. A scheduled monthly request with reminders at days 3, 7 and 12 turns "chase thirty" into "phone four". It is the same work repeated twelve times a year: that is where automation pays most. > [!NOTE] > When a client leaves, being able to hand over their whole file with its dates in one download says more about your firm than any sales argument. And some come back. **Can I give the client access to their own?** Yes, read-only and scoped to their case. **Does it serve for the identification file?** Documents are requested and kept like the rest, with their dates and expiries. **What about clients who send everything by WhatsApp?** You can request there, but the document ends up in the case, not on an adviser's phone. ## Ejemplos **A firm with 180 clients spends the first week of each month chasing documents.** - Schedules the monthly request with automatic reminders - Filters for who has not delivered by the 10th → Goes from chasing thirty to phoning four, and gets back a week a month. **Chasing clients for their papers takes up the month.** - Requests and chases automatically → The team reviews instead of nagging. **A client asks what they are missing and it has to be checked by hand.** - Shows them their own outstanding list → They answer without a phone call. **A client's documentation lives in the inbox of whoever handles them.** - Gathers the file in a shared place → The answer does not depend on who is in. **A client leaves and their material must be handed over.** - Checks their complete file → The handover is prepared in hours. **Every close-out chases the same things from the same clients.** - Reuses the process from one period to the next → The second close costs a fraction. --- --- id: KB-LE-001 url: https://app.codecontract.io/help/legal/document-control-in-professional-firms idioma: en categoria: sector-legal subcategoria: compliance audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-009, KB-CS-022] citadoPor: [KB-LE-004, KB-LE-009, KB-LE-033] --- # Document control in professional firms _You live on other people's documents: requesting, keeping and returning them whole._ **Responde a:** law firm document management · requesting documents from clients · accountancy document control · where to start professional firm documentation A firm lives on documentation that is not its own: it requests it, keeps it, uses it and one day returns it. That shifts the priorities compared with any other sector — here what matters most is separation between clients, and punctuality. ## The three moments | Moment | What fails | What prevents it | | --- | --- | --- | | Requesting | An email chain with no view of what is missing | One process per engagement type | | Keeping | Documents in a partner's inbox | Having them live in the client's case | | Returning | Two weeks gathering paper | One download with its dates | > [!IMPORTANT] > You hold documents for clients who compete with each other, and often personal data about their staff. One team per client is not internal tidiness: it is what stops an adviser seeing a competitor's material, and that is not just any slip. ## What gives back the most time Recurrence. Monthly or quarterly documentation is the same work repeated twelve or four times a year, and it is where automatic chasing turns "chase thirty" into "phone four". **En corto** - An engagement letter signed before starting: it avoids the commonest scope dispute. - A scheduled recurring request, with reminders. - And being able to hand over the whole file the day a client leaves. > [!WARNING] > Client documentation belongs to the client. Withholding it or delaying its return over an unpaid invoice is delicate ground: check with your professional body before doing it, not after. > [!NOTE] > Each branch adds its own — client identification, procedural deadlines, retention duties — but these three moments are common to all. **Can I give the client access to their own?** Yes, read-only and scoped to their case. **What about clients who send everything by WhatsApp?** You can request there, but it ends up in the case rather than on a phone. **Does it serve for the identification file?** Documents are requested and kept like the rest, with their dates. ## Ejemplos **A firm with 180 clients spends the first week of each month chasing documents.** - Schedules the monthly request with reminders - One team per client → Goes from chasing thirty to phoning four, and no adviser sees a competitor's material. **Each matter lives in the folder of whoever handles it.** - Centralises matters in one place → The firm stops depending on individuals. **A client asks for their material and it has to be reconstructed.** - Keeps an index per client of what is retained → The handover is prepared in hours. **The whole team can open everything.** - Limits access according to the engagement → Sensitive material stops being within everyone's reach. **A deadline approaches and nobody sees it.** - Records deadlines with a warning → The warning arrives with room to act. **Somebody leaves the firm with open matters.** - Reassigns the matters on departure → No client is left waiting. --- --- id: KB-LE-002 url: https://app.codecontract.io/help/legal/deadlines-and-evidence-in-proceedings idioma: en categoria: sector-legal subcategoria: procesal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-022, KB-TZ-004] citadoPor: [KB-LE-005, KB-LE-007, KB-LE-030] --- # Deadlines and evidence in proceedings _Documenting what was requested, when it arrived and what was communicated, without relying on memory._ **Responde a:** documentary evidence for proceedings · prove when i requested a document from a client · procedural deadlines documentation · evidencing communications with a client In proceedings, two things get argued before the substance: whether something was requested in time and whether something was communicated. Both are answered with dates you did not set, or they are not answered at all. ## What is worth being able to prove | Situation | What evidences it | | --- | --- | | Documents were requested from the client and never arrived | The request with its send and open dates | | A risk or a deadline was flagged | The communication certified on the day | | The client approved a course of action | Their signed agreement, not an email saying "go ahead" | | The file was handed over at the end | The handover with its receipt | > [!IMPORTANT] > The gap between "I warned them" and "they accepted" is everything. If a course of action has consequences for the client, send it for signature rather than communicating it: an email proves you said it, a signature proves they accepted. ## What not to do with live proceedings **En corto** - Do not reorganise or relabel anything related to the matter. - Do not delete anything, however irrelevant it seems. - Do not reconstruct afterwards a communication that was never certified at the time. > [!WARNING] > Every change is logged with its date. A document moved or renamed after proceedings begin always reads in the worst possible way, however innocent — and explaining it costs more credibility than the tidiness saves. > [!NOTE] > An engagement letter signed before starting avoids the scope dispute, which in this sector most often precedes a conflict with the client themselves. **Does a certified communication count as formal notification?** They are different things. If your procedure requires a specific form of notification, that remains mandatory; this is additional evidence. **How long do I keep the file?** According to your professional and retention duties; check with your professional body. **Can I give the client access during the matter?** Yes, read-only and scoped to their part. ## Ejemplos **A firm disputes with a client whether a deadline was flagged.** - Retrieves the communication certified that day → The argument closes with a date instead of two versions of the same conversation. **A deadline is counted mentally and cut fine.** - Records the deadline with its own warning → The margin does not depend on remembering. **The evidence sits in one person's inbox.** - Stores what matters in the file → The evidence outlives the person. **A document is submitted without its context.** - Also submits what accompanies it → The item is understood without explanation. **A missing document is discovered late.** - Reviews the file when opening the matter → The gap closes while there is time. **Two people handle the same matter without coordinating.** - They work on the same file → Nothing is duplicated or contradicted. --- --- id: KB-LE-003 url: https://app.codecontract.io/help/legal/handling-third-party-data-in-a-firm idioma: en categoria: sector-legal subcategoria: privacidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-013, KB-TZ-006] citadoPor: [KB-LE-008, KB-LE-009, KB-LE-021, KB-LE-025, KB-LE-032] --- # Handling third-party data in a firm _They are neither yours nor your client's: they belong to your client's staff and customers._ **Responde a:** personal data of my client's employees · law firm third-party data protection · data processor accountancy · how long to keep data of a client who left A firm handles a layer of data almost nobody else does: that of **its client's** employees and customers. People who did not engage you, do not know you, and never chose for their payslip or ID to pass through your hands. ## The three layers, and who answers for each | Layer | Whose it is | Your role | | --- | --- | --- | | Your firm's data | Yours | Controller | | Your client's contact data | The client company's | Usually controller | | Payslips, IDs and their staff's data | Those individuals' | Usually on your client's instructions | _The exact allocation of roles depends on the service and the contract; confirm with your adviser or data protection officer._ > [!IMPORTANT] > The third layer carries the most volume and receives the least attention. If your firm suffers a security incident, the people affected are not your clients: they are your clients' employees, and they bear the harm. ## What genuinely reduces the risk **En corto** - Ask for the minimum: many engagements need no ID copy, only the number. - One team per client, so nobody sees what is not theirs. - Delete when the period ends, rather than accumulating just in case. ## When a client leaves Return their complete file and apply your retention policy to the rest. Keeping the data of a former client's employees, with no obligation justifying it, is accumulating risk with no upside. > [!WARNING] > This is not legal advice and your specific duties depend on the service, the client contract and your professional rules. What is certain is that you will have to answer the question to someone: better to have thought it through first. > [!NOTE] > If a client asks for access to their own material, giving it scoped is safer than emailing everything: it leaves no loose copies and records what they looked at. **Do I need a specific contract with my client?** For processing on their instructions one is usually required; check. **Can I keep the file after the client leaves?** Whatever your professional rules require you to keep, and no more. **What if my client's employee asks me for their data?** Such a request normally goes to their employer, not to you; check before answering directly. ## Ejemplos **A firm keeps ID copies of employees of clients who left years ago.** - Checks what it is obliged to retain - Deletes the rest → Stops holding hundreds of identity documents belonging to people who are not even its clients. **A client's documentation arrives containing third-party data.** - Checks what it contains before filing it → You know what you are holding. **The whole firm can open any matter.** - Limits access according to the engagement → Access stops being general by default. **Everything is kept indefinitely just in case.** - Applies a retention policy → What is kept has a reason and a period. **A whole file is shared when one document would do.** - Shares only what is relevant → What was asked for is delivered, and nothing more. **A client asks what is held about them.** - Checks the index of their file → The answer is specific. --- --- id: KB-LE-004 url: https://app.codecontract.io/help/legal/building-a-compliance-process-people-use idioma: en categoria: sector-legal subcategoria: compliance audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-001, KB-CF-011, KB-LE-012] citadoPor: [KB-LE-011, KB-LE-019, KB-LE-024] --- # A compliance programme people actually use _The difference between having a manual and proving it is applied._ **Responde a:** compliance programme documentation · prove compliance is applied · compliance training records · evidence of a compliance programme A compliance programme is judged on one thing when the moment comes: whether it can be shown to have been alive before the problem. A manual approved three years ago and filed in a folder proves nothing — and whoever reviews it knows that. ## What must be provable | Element | What proves it | What does NOT | | --- | --- | --- | | That it exists | The programme, with a trusted approval date | A document in a shared folder | | That it is known | Training with who, when and a signed acknowledgement | An email with the manual attached | | That it is reviewed | Periodic reviews, dated | That the latest version is three years old | | That it is applied | Concrete cases detected and handled | That there have been none | > [!IMPORTANT] > The last row weighs most and is the most uncomfortable. A programme with no case recorded in three years does not prove everything is fine: it proves it is not being used, or that nobody dares use it. ## What makes it genuinely used **En corto** - Training with a signed acknowledgement and an expiry, like any other. - Reviews scheduled rather than waiting for someone to remember. - A trusted-dated record of every approved version. > [!WARNING] > Certifying the programme on the day it is approved and at each review has a concrete purpose: if one day you must show it existed before an event, the date cannot be whatever your file server says. ## What a tool cannot do Design the programme, decide which risks apply to you, or judge whether it is sufficient. That is your adviser's or compliance officer's work. What it can do is leave a dated record of everything you do, which is exactly what is hard to reconstruct afterwards. > [!NOTE] > If your programme requires certain third parties to sign up to a code of conduct, that is precisely a signature request with tracking: who signed, when, and who is missing. **Do training records count as evidence?** With a signed acknowledgement and a date, they are what is asked for. **What if we detect a case?** Recording and handling it is what sustains the programme, not what weakens it. **Is this advice?** No. The programme's content is defined by whoever should; this explains how to record it. ## Ejemplos **A company approved its programme four years ago with no evidence it is applied.** - Certifies the current version - Launches training with signed acknowledgement - Schedules the annual review → Six months later it can show the programme is alive, which is all that is asked. **The programme exists in a document nobody opens.** - Turns it into tasks with an owner and a date → The programme leaves a trail that it is used. **Training happens and nothing is recorded.** - Records who did it and when → The evidence exists when it is asked for. **An auditor asks for evidence and is shown the manual.** - Shows the record of real operations → The control moves from assertion to evidence. **Periodic reviews happen whenever somebody remembers.** - Schedules the reminders by calendar → The cadence keeps itself. **The organisation changes and the programme stays the same.** - Reviews it when something relevant changes → The programme describes today's company. --- --- id: KB-LE-005 url: https://app.codecontract.io/help/legal/when-a-notary-is-needed-and-when-not idioma: en categoria: sector-legal subcategoria: notariado audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-012, KB-LE-002] citadoPor: [KB-LE-010] --- # When a notary is needed and when not _Electronic signature covers a lot, but not everything. Where the line is._ **Responde a:** can i sign this without a notary · which documents need a notarial deed · does electronic signature replace a notary · notarising an electronically signed contract The question arrives as soon as someone gets used to signing without travelling: does this count too? The short answer is that most business-to-business contracts do, and a few do not — and the few that do not are fairly well defined. ## The line, broadly | Type of document | Normally | | --- | --- | | Commercial contracts between companies | Electronic signature suffices | | Employment agreements and amendments | Electronic signature suffices | | Professional engagements and sign-offs | Electronic signature suffices | | Acts the law subjects to a notarial deed | A notary is required, and electronic signature does not replace one | | Acts requiring registration | Check: the formal requirement governs | _This is indicative. What your specific document requires is stated by the rule governing it, not by a table._ > [!IMPORTANT] > Where the law requires a form — a notarial deed, notarial intervention, registration — that form is a requirement, not a recommendation. No electronic signature, however advanced, replaces it, and signing that way an act which required it can leave it ineffective. ## What electronic signature does solve in those cases Everything around the notarial act: the preliminary agreement, prior sign-offs, the documentation to be gathered beforehand, later amendments. That is usually ninety per cent of the paperwork, and where the time goes. **En corto** - Gathering documentation before the signing, with tracking. - Signing everything ancillary without travel. - And keeping what was signed with its date and evidence. > [!WARNING] > This article cannot tell you whether your specific document needs a notary. What it can do is prevent the reverse mistake: do not stop signing everything else electronically because of doubt about one. > [!NOTE] > If you have recurring doubts about one document type, ask your adviser once and write the answer down. It is a consultation that serves every later case. **Can something signed electronically be notarised?** That is a question for your notary; it depends on the document and how it was signed. **Is it valid outside Spain?** The European framework recognises electronic signatures across the EU; outside it depends on the country. **Does a qualified signature replace a notary?** No. They are different things covering different requirements. ## Ejemplos **A company stops signing commercial contracts electronically over doubt about one that needed a notary.** - Asks once which types require a formal deed - Keeps signing the rest electronically → Recovers the saving on 95% of its documents without risking the 5% that genuinely required the form. **Something that did not need it is taken to the notary.** - Checks beforehand what that act requires → A formality and a cost are saved. **Something that did require it is signed without a notary.** - Checks with the adviser before signing → The act happens where it should. **A document is missing on signing day.** - Checks the list in advance → The appointment is not repeated. **The notarial copy is kept in a drawer.** - Captures and stores it in the file → It is found without going to the archive. **A copy is requested years later.** - Keeps the file with its date → The request is resolved without a new formality. --- --- id: KB-LE-006 url: https://app.codecontract.io/help/legal/payroll-and-hr-for-multiple-clients idioma: en categoria: sector-legal subcategoria: laboral audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-022, KB-CF-007] citadoPor: [KB-LE-007] --- # Running payroll and HR for several clients _Many different calendars, many deadlines, and data about people who are not yours._ **Responde a:** payroll bureau client documentation · hires and leavers for several clients · client payroll document management · employment deadlines across companies Running payroll and HR for thirty companies is not doing the same thing thirty times: it is doing the same thing with thirty different calendars, thirty contacts and thirty ways of sending you things late. And with data about people who belong neither to you nor to your client: it is theirs. ## What repeats every month | What | Who it depends on | What happens if it is late | | --- | --- | --- | | Payroll variables | The client | The whole chain slips | | Hires and leavers | The client, with legal deadlines | The only thing that tolerates no delay | | New employee documentation | The worker, via the client | You can start without it, but better not | | Contract and amendment signatures | The worker | It blocks the hire if it does not arrive | > [!IMPORTANT] > Hires tolerate no margin and arrive latest, because the client tells you when the person is already working. A recurring request with reminders does not fix it entirely, but it turns "I found out on the 20th" into "I asked on the 1st and it is on record". ## The data you handle is not your client's Payslips, identity documents, sometimes health data. They belong to your client's workers, people who never engaged you. One team per client is not internal tidiness: it is what stops one company's adviser seeing another's payroll. **En corto** - One team per client, with scoped permissions. - Ask for the minimum: many tasks need no ID copy. - And delete when the period ends, rather than accumulating. > [!WARNING] > When a client leaves, return their file and apply retention to the rest. Keeping the payslips of a former client's workers, with no obligation justifying it, is pure risk. > [!NOTE] > A scheduled monthly request with reminders at days 3, 7 and 12 turns the first week of each month from a phone campaign into four calls. **Can I give the client access to their own?** Yes, scoped to their company. **What about the workers' signatures?** They sign from their phones; they need no account and need not know you. **How long do I keep it after a client leaves?** Whatever your professional and employment rules require; check. ## Ejemplos **A payroll bureau with 34 clients spends the first week of each month chasing variables.** - Schedules the monthly request with reminders - One team per client → The first week goes from thirty calls to four, and no adviser sees another client's payroll. **Each company sends its returns through a different channel.** - Agrees a single delivery channel → Deliveries stop getting lost. **An onboarding arrives on the day the person starts.** - Requests documentation in advance → Onboarding is prepared before day one. **A client asks what they are missing every month.** - Shows them their own outstanding list → They answer for themselves. **A worker's documentation expires.** - Records expiries per person → The warning arrives before it bites. **Every close chases the same things.** - Reuses the process from one month to the next → Follow-up stops being rebuilt. --- --- id: KB-LE-007 url: https://app.codecontract.io/help/legal/insurance-broking-and-claims idioma: en categoria: sector-legal subcategoria: seguros audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-002, KB-TZ-002, KB-LE-006] citadoPor: [KB-IC-016] --- # Insurance broking and claims _Documentation arriving at the worst moment, on deadlines that do not wait._ **Responde a:** claim documentation · broker client document management · claim notification deadlines · gathering documents for an insurer A claim arrives without warning, with an upset client and deadlines running from the event, not from when you find out. Everything you can have ready beforehand is worth double at that moment. ## What to have before anything happens **En corto** - Each client's current policy, with its effective date. - Real contact details, not the email from three years ago. - And the cover history, because the claim may belong to an earlier policy. > [!IMPORTANT] > The last point fails most often. A claim surfacing today may correspond to cover in force two years ago, and answering that requires the dated history — not the current policy. ## When it happens 1. **Document the event as soon as possible** — Certified photos the same day. Damage photographed three weeks later is no longer the same damage. 2. **Gather what the insurer asks for** — As a process, not an email chain: the client is upset and will not send five things in a row. 3. **Record every communication** — With dates. Notification deadlines are the most disputed point afterwards. > [!WARNING] > Claim notification has deadlines and missing them can affect cover. Certifying when and what was communicated protects your client, and protects you from the claim that follows if something goes wrong. ## What an insurer disputes | What is questioned | What closes it | | --- | --- | | When it happened | Photos and communication with a trusted date | | What condition it was in before | Prior documentation, if it existed | | When it was notified | The communication record | | Which cover applied | The policy history with its dates | > [!NOTE] > If you handle claims often, build document collection as a recurring process. The client and the event change; the insurer's list changes little. **Can I give the client access to their file?** Yes, scoped, and during a claim it is very reassuring. **And the insurer?** Scoped access or an export, depending what they accept. **How long do I keep a closed claim?** Limitation periods are long; check with your adviser. ## Ejemplos **A broker handles a claim whose cover belonged to a policy from two years earlier.** - Retrieves the policy history with its effective dates → Evidences the cover applicable at the time of the event, rather than arguing with the current policy in hand. **A claim arrives and the client's documentation is missing.** - Requests what is missing from day one → The file moves while it is being worked. **Claim documentation arrives through several channels.** - Gathers everything in the claim's file → What is there and what is missing is visible at once. **The client asks how it is going and it has to be looked up.** - Checks the file's status → You answer there and then. **A policy expires and the client does not know.** - Records expiries per client → The warning arrives before renewal. **Months later how it was handled must be explained.** - Keeps the file's history → The explanation comes from the file. --- --- id: KB-LE-008 url: https://app.codecontract.io/help/legal/the-document-room-in-a-deal idioma: en categoria: sector-legal subcategoria: despachos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-003, KB-IC-010, KB-LE-029] citadoPor: [KB-LE-012, KB-LE-013, KB-LE-016, KB-LE-017, KB-LE-028] --- # The document room in a deal _Who saw what, when, and why that matters more than the folder._ **Responde a:** setting up a data room for due diligence · sharing documents in an m&a deal · controlling who sees what in a transaction · access log for confidential documents In a sale, a financing round or a new partner coming in, the document work looks like a storage problem and is not. What is at stake is traceability: who saw what and when, because what can be argued later depends on it. ## The three questions that arrive when a deal sours | Question | What answers it | | --- | --- | | "You never showed us that" | The record of what was made available and when | | "We saw it after signing" | The access date, not the upload date | | "That document was changed" | The versions, with the earlier one kept | > [!IMPORTANT] > The second is the one most often lost. Uploading a document does not prove the other side saw it; the access log does. An ordinary shared folder gives you the first and not the second. ## How to organise it without chaos 1. **One file per deal, with its own index** — The index is a deliverable, not decoration: it is what the other side works through. 2. **Per-person access, not a shared password** — If everyone logs in with the same credentials, the log says nothing. 3. **In phases** — Basics first; sensitive material as the deal advances and not before. 4. **And a question-and-answer record** — What was asked and what was answered belongs in the file as much as the documents. > [!WARNING] > The costliest mistake is opening everything on day one "to move fast". If the deal falls through, you have handed your full information to someone who may be a competitor, with no tiers to show how far each party got. ## When the deal closes **En corto** - Access is closed, and the closing date is recorded. - The whole file is kept, old versions included. - And the access log is preserved — the first thing requested if there is litigation years later. > [!NOTE] > The same applies to small deals. A firm handling share transfers in family businesses has the same problem in miniature, and usually solves it by email — which is exactly where no record exists. **Can downloads be blocked?** They can be limited, but assume anything visible can be photographed. The log remains the real protection. **How long must it be kept?** Longer than the deal: claim periods run in years. **Does it work for insolvency or probate?** Yes, for the same reason: the problem is not storing, it is proving who saw what. ## Ejemplos **A firm handles the sale of a family business and shares everything by email.** - Sets up the file in phases with per-person access - Keeps the access log after closing → Two years later, facing a hidden-defects claim, it can show what was made available and when it was viewed. **A folder is shared and nobody knows who saw what.** - Controls access and leaves a trail of what was viewed → The handover is orderly and verifiable. **Documentation is uploaded containing material that should not be shown.** - Reviews the content before sharing → Nothing extra is handed over. **The other side asks for something already uploaded.** - Checks the index of what was shared → You answer without re-uploading. **The deal ends and access stays open.** - Revokes access on closing → The room does not stay live without reason. **Nobody knows what is still outstanding.** - Checks the status of what was requested and delivered → The process runs on a list. --- --- id: KB-LE-009 url: https://app.codecontract.io/help/legal/onboarding-a-new-client-at-a-firm idioma: en categoria: sector-legal subcategoria: compliance audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-001, KB-LE-003] citadoPor: [KB-LE-010, KB-CN-008, KB-CF-016, KB-LE-019] --- # Onboarding a new client at a firm _Identification, conflict check and written engagement, before any work starts._ **Responde a:** client onboarding at a law firm · client identification anti money laundering · engagement letter · checking conflicts of interest Client onboarding at a firm is often handled with a phone call and a new folder. It is the moment three separate obligations are taken on, and all three are far cheaper to meet before starting than after. ## The three things to close | Front | What you need | Why beforehand | | --- | --- | --- | | Identification | ID document, beneficial ownership for companies | Starting work without it is already a breach | | Conflict of interest | A check against your client base | Afterwards it means resigning the engagement | | Written engagement | Scope, fees and what is excluded | It is what prevents the argument at the end | > [!IMPORTANT] > The second costs most when skipped. Discovering three months in that you act for the other side in another matter is not fixed with an apology: it is fixed by resigning the engagement, sometimes both. ## How to do it without slowing intake 1. **One onboarding process for everyone** — Asking the same things every time, so nobody decides ad hoc what to request. 2. **Documents supplied by the client, not chased by you** — Send a request and they upload theirs; the work is shared. 3. **The conflict check, recorded** — Doing it is not enough: you must be able to show it was done and when. 4. **And the engagement signed before the first action** — Signed from a phone the same day, not a PDF returning in two weeks. > [!WARNING] > The urgent case is what breaks the system: a client arriving with a deadline the day after tomorrow. Decide calmly what minimum is non-negotiable even then — usually identification and conflict — and what can be completed within 48 hours. ## What you must be able to show years later **En corto** - That you identified the client, and when. - That you checked for conflicts before accepting. - The scope agreed, in the signed version. - And identification updates, if the relationship is long. > [!NOTE] > The last point is always forgotten. Identification is not a one-off: in long relationships it must be refreshed, and a company can change beneficial owner without telling you. **Does it apply to small private clients?** The obligation depends on the type of service, not the client's size. **What if the client refuses to identify?** That is grounds not to accept, and it should be recorded. **Can the client upload their own documents?** Yes, by their link, with no account and without their documents circulating by email. ## Ejemplos **A firm takes on an urgent matter and completes identification three weeks later.** - Defines a non-negotiable minimum for urgent cases - Sends the document request to the client the same day → Urgent onboardings close within 48 hours with the conflict check recorded. **A client is accepted and their documentation arrives months later.** - Requests what is needed before starting → The engagement starts complete. **Each person asks for different things at onboarding.** - Uses one onboarding template → The files are comparable. **An onboarding document expires and nobody reviews it.** - Records validity on receipt → The file stays true. **There is no record of what was checked on accepting the client.** - Records the checks performed → The decision to accept is explicable. **An old client never went through the current onboarding.** - Checks what is missing in the older files → The gap closes without waiting for a review. --- --- id: KB-LE-010 url: https://app.codecontract.io/help/legal/probate-and-family-documentation idioma: en categoria: sector-legal subcategoria: notariado audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-005, KB-LE-009] citadoPor: [KB-LE-032] --- # Probate and family documentation _Several heirs, documents supplied by each, and a process that runs for months._ **Responde a:** probate documentation · gathering papers from several heirs · estate administration documents · coordinating a family to sign An estate has an unusual combination: a lot of documentation, several people supplying it at different speeds, tax deadlines that do not wait, and an emotional context that makes chasing paperwork especially uncomfortable. ## Where each item comes from | Supplied by | What | Usual pace | | --- | --- | --- | | Each heir | Identity, tax details, acceptance | Very uneven between them | | The firm | Certificates, registry searches, calculations | Fast, given the data | | Third parties | Banks, insurers, institutions | Slow and on their own schedule | > [!IMPORTANT] > The bottleneck is almost always the first row, and not out of ill will: these are people who do not do this for a living, sometimes living far away, receiving a document request at a difficult time. Making it easy to supply is half the work. ## How to shorten it 1. **Ask each heir only for their own** — A personal list, not the file's full list. It reduces paralysis. 2. **Let them supply from a phone** — A photo of the document and done, no account, no scanner, no travel. 3. **Leave chasing automatic and gentle** — Spaced out. More effective, and it stops the firm looking like the one applying pressure. 4. **And keep visible what is missing and from whom** — The question everyone asks, every week. > [!WARNING] > Beware the inbox of whoever handles the family. When all documentation lands with one person, the matter stalls whenever they are away, and in a file running for months that always happens. ## Deadlines **En corto** - Tax deadlines rule and do not move. - Count backwards from them, not forwards from today. - And state the deadline in the first request, not the third. Saying up front when each item is needed changes behaviour far more than chasing afterwards. > [!NOTE] > Everything supplied stays in the estate's file, not in separate emails. Years later, if someone disputes what was done or what was received and when, that is the answer. **Does each heir need an account?** No: each enters by their link and sees only their own. **Can they see what the others supply?** Only if you decide so; not by default. **Does it work for other family matters?** Yes: divorces, guardianships, transfers between relatives. Same mechanics. ## Ejemplos **A firm handles an estate with five heirs, three of them abroad.** - Sends each their personal list to supply from a phone - Leaves spaced reminders on automatic → Documentation completes weeks before the tax deadline and without awkward calls. **The documentation is spread across several family members.** - Gathers what is provided into one shared file → There is one picture. **A document is missing and nobody knows who held it.** - Records what each person provided and when → The gap has an addressee. **The matter runs for months and the contact changes.** - Keeps the file accessible to whoever it concerns → The change does not restart the work. **Personal documents are handled with no access criteria.** - Limits who sees what → Sensitive material is not within everyone's reach. **Years later a copy is requested.** - Keeps the file with its date → The request is resolved without rebuilding anything. --- --- id: KB-LE-011 url: https://app.codecontract.io/help/legal/running-compliance-for-several-clients idioma: en categoria: sector-legal subcategoria: compliance audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-004, KB-CL-008] citadoPor: [KB-LE-014, KB-LE-021] --- # Running compliance for several clients _A firm or consultancy with twenty clients: the same thing twenty times, without mixing it up._ **Responde a:** managing compliance for several clients · consultancy running outsourced compliance · keeping each client's documentation separate · obligations calendar per client Running compliance for twenty companies has a double problem: doing the same thing twenty times without it getting mixed up, and being able to show separately, client by client, what was done and when — because whoever answers to an inspection is each client, not you. ## The three risks specific to this work | Risk | How it shows up | How to avoid it | | --- | --- | --- | | Documentation getting mixed | One client's file ends up in another's | Real separation, not folders with similar names | | Missing a deadline | Twenty calendars in two people's heads | Due dates with warnings and an owner, per client | | Being unable to show what was done | The client says you never warned them | Communications recorded in their file | > [!IMPORTANT] > The third affects you directly. If a client fails at something you warned them about, your defence is being able to show when you told them. If that warning lived in the inbox of someone who has left, it does not exist. ## How to organise it 1. **A space per client, not a folder per client** — Separation must be effective, especially if two clients compete. 2. **An obligations calendar per client** — With warnings and an owner inside your team. 3. **Every relevant communication, in their file** — Warnings, deliveries, reminders. Not in the inbox of whoever handles them. 4. **And what the client supplies, through their own route** — Let them upload it, with a record, rather than emailing you. > [!WARNING] > The fourth point saves more time than it looks. Much of a compliance consultancy's work is not analysis: it is chasing clients to send their material. Having each client supply via their link, with automatic reminders, removes nearly all of that. ## What the client should see **En corto** - Their status: what is current and what is missing. - What you have asked them for, and since when. - And what was delivered, with dates, so they do not send it twice. That transparency cuts the "how are we doing?" calls and, above all, makes what you do visible: much of this service's value is invisible until it is shown. > [!NOTE] > It applies equally to an employment adviser, a safety consultancy, an accountancy firm or a practice handling clients' data protection: the obligations list changes, the mechanics do not. **Can one client see another's material?** No, if they are properly separated. That is this model's main requirement. **What if a client wants to take theirs away?** Their complete file is exported; it is theirs. **How do we bill extra work?** With the record of what was requested and delivered in front of you, which is exactly what usually goes missing. ## Ejemplos **A consultancy runs compliance for eighteen companies using folders and email.** - Separates by client and builds the obligations calendar with owners - Has each client supply via their link → Stops chasing by email and can show, client by client, what it warned and when. **Each client has their own circuit and none resemble each other.** - Uses one adaptable template → Improvements reach everyone. **What needs reviewing per client and when gets lost.** - Schedules the reviews by calendar → The cadence keeps itself. **A client asks for evidence of one specific control.** - Checks that client's record → It is provided without reconstructing. **The person handling a client changes.** - Keeps the file independent of individuals → The handover does not lose context. **A gap is found at one client and there may be more.** - Checks the same point across the rest → What is learned at one serves all. --- --- id: KB-LE-012 url: https://app.codecontract.io/help/legal/intellectual-property-proving-it-was-yours idioma: en categoria: sector-legal subcategoria: propiedad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-SC-011, KB-LE-008] citadoPor: [KB-LE-004] --- # Intellectual property: proving it was yours _Registering is one thing and proving it existed earlier is another. You usually need both._ **Responde a:** how to prove an idea is mine · proving the creation date of a design · protecting a development without registering it · trade secret documentation In a dispute over who created what, the argument is rarely about the content: it is about **when** it existed and in whose hands. And that part is not solved by registration, it is solved by what you kept while working. ## The three layers, and what each is for | Layer | What it gives | What it does NOT give | | --- | --- | --- | | Formal registration (trade mark, design, patent) | A right enforceable against third parties | It does not prove what you did before registering | | Contracts with whoever created it | That the rights are yours and not the maker's | It does not prove the creation date | | Evidence with a provable date | That the content existed on that date and has not changed | It does not prove you were the creator | > [!IMPORTANT] > The third column of the last row is worth understanding before relying on it. Sealing a file proves **date and non-alteration**, not authorship: it says the document existed in that form on day X and was in your possession, not that you made it. That is a great deal in a priority dispute and insufficient when the argument is about who created it — for that you have contracts and the trail of the work. ## What to keep while working 1. **Intermediate versions, not only the final one** — A draft with its corrections proves a process; the final result proves only a result. 2. **Who did each part and when** — Especially where freelancers, agencies or interns were involved. 3. **Contracts with everyone involved, signed before starting** — An assignment signed afterwards works worse and sometimes does not work. 4. **And what you showed third parties, with dates** — Before a trade fair, a client meeting or a demo, seal what you are about to show. > [!WARNING] > Point three prevents the most grief in small companies. If an outside agency designed your brand or a freelancer wrote part of the code, the rights are not automatically yours because you paid the invoice: they depend on what the contract says. And that conversation is easy before starting and awkward three years later. ## Trade secrets follow a different route **En corto** - They are not registered: they are protected by keeping them secret and being able to show it. - That means signed confidentiality agreements and access that is limited and logged. - If everyone in the company can see it and nobody signed anything, it stops being a protectable secret. Here the record of who accessed what stops being a convenience and becomes part of the protection: it is how you show you treated that information as confidential. > [!NOTE] > What can be registered, where, and with what effect varies by type of creation and by territory, and a trade mark is not the same as a design or a piece of software. **What you should register and with what scope is a question for your lawyer**; what is described here is what to keep so that conversation starts with material rather than recollections. **Does sealing a file replace registration?** No. They are different and complementary: one gives a right, the other gives a date. **What if the dispute is with a former employee?** There the contract, what they signed and the record of what they accessed all weigh. **Is emailing it to yourself any use?** Better than nothing and rather weak: the date depends on a mailbox you control. ## Ejemplos **A company finds a competitor launching something very like its own development.** - Retrieves the sealed intermediate versions and the contracts of everyone involved → It can establish when it existed and that the rights are its own, instead of arguing from memory. **The file's modified date is relied upon.** - Timestamps the work when it is finished → The date does not depend on the computer. **A design is shown to a client with no prior record.** - Timestamps before showing it → Priority in time is provable. **Similar work appears months later.** - Checks the timestamp of the original version → The date does not rest on your word. **The work evolves through several versions.** - Timestamps each relevant version → Each step can be placed in time. **It must be proved without revealing the content.** - Shares only the fingerprint → The proof travels without the work. --- --- id: KB-LE-013 url: https://app.codecontract.io/help/legal/the-life-of-a-contract-after-signing idioma: en categoria: sector-legal subcategoria: contractual audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-008, KB-TZ-014, KB-LE-023] citadoPor: [KB-NO-017, KB-LE-030] --- # The life of a contract after signing _Negotiated for weeks, signed in a day, and then it lives three years with nobody looking at it._ **Responde a:** contract management after signing · i do not know when the contract ends · automatic contract renewal · tracking contractual obligations All the effort goes into negotiation and signing. Afterwards the contract is filed and the long part begins: three years generating obligations, deadlines and renewals that nobody is watching because the document is closed. ## The four dates to pull out of the text | Date | Why it matters | What happens if it is missed | | --- | --- | --- | | End of term | The obvious one and usually the only one noted | Service continues with no cover | | Non-renewal notice | It falls before the end, sometimes long before | It renews for another whole year unintentionally | | Price review | Usually has its own window | Last year's terms roll on unreviewed | | Milestones and deliverables | What must happen during the term | Something nobody remembered gets breached | > [!IMPORTANT] > The second costs the most money and is noted the least. A contract with automatic renewal and a notice period forces a decision **months before** it ends; if the alert fires on the expiry date, it has already renewed. This is where reminder margin is not a convenience: it is the difference between being able to leave and not. ## What to extract when filing it 1. **The parties and who signed for each** — With their role: it is the first thing asked if authority is disputed. 2. **The four dates, as alerts with an owner** — Not in the head of whoever negotiated, who may not be here in two years. 3. **The conditions that bind you** — Service levels, insurance to maintain, confidentiality, exclusivities. 4. **And where the signed original is** — With its version: later annexes amend the text and belong alongside it. > [!WARNING] > The silent error is filing the contract and its annexes separately. Two years on, someone reads the original, quotes a clause, and it turns out it was amended by an annex signed six months later that nobody linked. The contract in force is not the document: it is the document plus its amendments. ## During the relationship **En corto** - Anything agreed by email that changes terms, kept with the contract. - Incidents, in the same file: they are what supports a renegotiation. - And formal communications, with delivery evidence and to whoever the contract names. That last one has a specific trap: many contracts designate an address or person for notices, and notifying someone else can count as not notifying. Worth checking before sending a notice, not after. > [!NOTE] > Which deadlines and formalities each contract requires depends on what was signed and the applicable law. **To know whether a notice is valid, how it is counted or what form it needs, ask your lawyer**; what is described here is how to keep findable what that lawyer will need. **Is it worth it for small contracts?** For self-renewing ones, yes: they are the most forgotten. **What if the contract is on paper?** Scan it and extract the dates all the same; the paper stays where it was. **Who should receive the alerts?** Whoever can decide, not whoever filed it. And a deputy. ## Ejemplos **A company discovers a services contract renewed for another year by accident.** - Extracts the four dates from each contract, with the notice period as its own alert - Links annexes to the original contract → The next renewal is decided two months ahead, not when the invoice arrives. **The contract is signed and simply filed.** - Records its key dates with a warning → Renewals and expiries stop surprising anyone. **A change is agreed by email and never reaches the contract.** - Files the agreement with the contract it amends → What was agreed later lives with what was agreed before. **Nobody knows which contracts expire this quarter.** - Checks expiries by date → Renewal is negotiated with time. **A contract auto-renews without anyone reviewing it.** - Warns before the rollover date → Renewal becomes a decision. **A specific clause is hunted across twenty contracts.** - Searches by content rather than file name → It is found without opening them all. --- --- id: KB-LE-014 url: https://app.codecontract.io/help/legal/period-end-and-the-documents-that-arrive-late idioma: en categoria: sector-legal subcategoria: fiscal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-022, KB-LE-011] citadoPor: [KB-LE-027] --- # Period end and the documents that arrive late _Every period end is the same race with the same clients, and it is won before the deadline or not at all._ **Responde a:** collecting client documents for period end · clients send invoices late · quarterly close accountancy · chasing documents from clients An accountancy practice does not have a workload problem: it has a calendar problem. The work bunches into a few days because clients send when they remember, and the part that consumes time is not filing — it is chasing and reconstructing who sent what. ## The three gaps that repeat every period end | Gap | How it shows | What closes it | | --- | --- | --- | | Incomplete documentation | The same items missing from the same clients | A fixed request with a list, not a generic email | | Documentation arriving badly | Illegible photos, protected PDFs, items from another period | Saying so on receipt, not at closing | | Documentation that arrived and cannot be found | It is in someone's inbox | Having it come in through the client's route, not a mailbox | > [!IMPORTANT] > The third causes the most arguments and looks least like a process problem. When a client says "I sent you that" and is right — they did, to the inbox of someone on holiday — the conversation stops being about their delay and becomes about your organisation. Having submissions always arrive through the same place removes that conversation entirely. ## What changes the outcome, built once 1. **One request per client and period, always the same** — With that client's specific list, not a circular. 2. **Start before the period ends** — What is requested on day 1 arrives in time; what is requested on day 20 does not. 3. **Automatic, spaced reminders** — It is the part a person does today and need not. 4. **And a visible list of who is missing** — For the targeted final push, and for the conversation afterwards. > [!WARNING] > The nuance that protects the practice: **keep evidence of what you requested and when**, not only of what you received. If a year later there is a review and the client insists they gave you something, what places you is not your memory: it is the dated request with what was asked and the record of what arrived. Without that, it is word against word and you are the one holding it. ## What you can show the client **En corto** - What they are missing, in plain language. - What they delivered and when, so they do not send it twice. - And how long it has been outstanding, which is what changes behaviour. That visibility cuts "is it all in yet?" calls and, above all, moves the ball: a client who can see their gap fills it sooner than one who has to be phoned. > [!NOTE] > Deadlines and what documentation is mandatory depend on each client's regime and they change. **That is your territory and your professional judgement**; what is described here is how to collect and evidence, not what must be filed. **What about clients who send everything on paper?** Have them photograph it from their phone via their link: it is what gets adopted most. **Is it worth it for a small portfolio?** The saving is in repetition: twenty clients every quarter already justify it. **Can I give the client access to their own file?** Yes, and it usually cuts status queries considerably. ## Ejemplos **A practice spends the last five days of each quarter chasing documents.** - Sends the per-client request on day one of the period and leaves reminders on automatic → Reaches the deadline with most of it complete and with a record of what was asked of whom, and when. **Close-out documentation arrives in January.** - Requests through the year what will be needed → Close-out stops being a campaign. **A client sends their material whenever they remember.** - Requests and chases automatically → Follow-up occupies nobody. **A document is missing and the close is delayed.** - Checks what is missing per client → The gap shows before the date. **The close uses a provisional figure and nobody corrects it.** - Flags what is provisional and reviews it → What is pending is not forgotten. **The next close repeats the same work.** - Reuses the previous period's process → The second close costs a fraction. --- --- id: KB-LE-015 url: https://app.codecontract.io/help/legal/justifying-a-public-grant idioma: en categoria: sector-legal subcategoria: administrativo audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CC-013, KB-TZ-011] citadoPor: [KB-LE-022] --- # Justifying a public grant _The hard part is not getting it: it is proving, two years later, that it was spent on what you said._ **Responde a:** grant justification documentation · asked to justify a grant from two years ago · what to keep for a funded project · grant audit what they ask for A public grant has two widely separated moments: when it is applied for, with everyone paying attention, and when it is justified or reviewed — sometimes years later, with the project finished, the staff changed and the documents split across three places. ## What is asked for at justification, and when it must date from | Element | What it proves | When it is produced | | --- | --- | --- | | Invoices and payments | That the expense existed and was paid | During the project | | That it matches the grant's purpose | That it was spent on what was awarded | Decided when spending, not when justifying | | Quotes or comparisons, where required | That the choice followed criteria | Before contracting: it cannot be redone after | | Publicity or acknowledgements, where required | That the condition was met | During, with photographic evidence | > [!IMPORTANT] > The third row sinks the most justifications and is the only one that **cannot be reconstructed**. If the call required several quotes before contracting and only one was sought, no document produced afterwards fixes it: the date gives it away. What must be captured is the moment before contracting, which is exactly when nobody is thinking about justification. ## How to organise it from the start 1. **One file per grant, not per project** — The project may include more spend than is funded; mixing them complicates justification. 2. **Each expense linked to its evidence from day one** — Invoice, payment and the criterion by which it falls under the grant. 3. **The call's conditions, inside and visible** — It is what nobody rereads and where the forgotten obligations live. 4. **And evidence of what is not an expense** — Photos of required publicity, minutes, attendance lists: always lost. > [!WARNING] > The nuance that surprises years later: **the review is not necessarily done by whoever awarded the grant, nor within the timeframe you expect**. It can come much later, from another body and with different criteria, and what is checked is what is recorded, not what you remember. That is why a grant file is kept well beyond the project's end, and kept complete. ## If something cannot be justified **En corto** - Saying so before they find it changes the conversation entirely. - An expense that does not fit is withdrawn from the justification, not dressed up. - And if part must be repaid, a voluntary partial repayment beats a review with findings. That last is not a moral point: a justification that collapses entirely casts doubt on the rest, and the consequences usually reach beyond that particular grant. > [!NOTE] > What each call requires, which retention periods apply and how justification works vary by programme and authority, and change with every call. **Read the terms and confirm with your adviser**; this describes what to keep from day one so that justification is possible at all. **What if the supplier no longer exists when the invoice is requested?** You hold the invoice: what matters is having kept it, not that they survive. **Does an email count as a quote comparison?** It depends on the terms; keep it anyway, dated, and ask before contracting. **How long must it be kept?** Longer than the project lasts, and considerably longer than people assume. ## Ejemplos **A company faces a review of a three-year-old grant and is asked for the compared quotes.** - On the next grant, files the quotes before contracting → Justification stops depending on reconstructing something only capturable at the time. **The claim is prepared at the end of the project.** - Stores supporting documents as they are generated → The claim is prepared without a campaign. **A supporting document from a year ago is missing.** - Records what was requested and what was obtained → The gap closes while it is easy. **Supporting documents are spread across departments.** - Gathers everything in the project's file → What is there and what is missing is visible at once. **A cost turns out not to fit when claiming.** - Checks eligibility when recording the cost → The problem is caught while it can be corrected. **A review asks years later.** - Keeps the complete file with its date → You answer from the archive. --- --- id: KB-LE-016 url: https://app.codecontract.io/help/legal/the-corporate-records-everyone-asks-for idioma: en categoria: sector-legal subcategoria: mercantil audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-008, KB-CR-018] citadoPor: [KB-LE-020, KB-LE-027, KB-LE-028] --- # The corporate records everyone asks for _Deeds, powers of attorney and minutes: rarely looked at, always asked for at the worst moment._ **Responde a:** asked for the company's incorporation deed · proving signing authority · where are the board minutes · corporate documents for a bank There is a set of documents almost no company looks at day to day and that turns up at the same moments every time: opening an account, entering a tender, selling the company, contracting with a large client. Always in a hurry, because whoever is asking already has their clock running. ## What is asked for and why | Document | What it proves | Who usually asks | | --- | --- | --- | | Incorporation deed and articles | That the company exists and how it works | Banks, tenders, transactions | | Later deeds | Changes of address, capital, purpose | Anyone needing the current version | | Powers of attorney | That whoever signs may sign | Everyone, and it is what fails most | | Shareholder and board minutes | That decisions were taken properly | Buyers, auditors, banks | | Beneficial ownership | Who stands behind the company | Banks and clients with due-diligence duties | > [!IMPORTANT] > The third row breaks deals at the last minute: **a power of attorney existing is not enough, it must be current and cover exactly what is being signed**. Powers get revoked, expire and are sometimes granted for something else; and whoever receives the signature checks precisely that. Finding out on signing day means postponing, because granting a new power is not an afternoon's work. ## How to keep it ready without being a law firm 1. **One corporate file, not a folder per year** — What is asked for is the current picture, not the archive. 2. **With the version in force marked as such** — Articles amended three times confuse whoever reads them. 3. **Powers with who, for what and until when** — And reviewed whenever someone changes role or leaves. 4. **And minutes filed as signed, not when requested** — Reconstructing an old set of minutes is the slowest part of any deal. > [!WARNING] > What almost nobody anticipates: **when someone leaves the company, their powers do not leave with them**. Cutting their email and access is instant; revoking a power of attorney is a formal act that has to be carried out, and until it is, that person can still bind the company towards a third party acting in good faith. It is the most forgotten task in any departure, and the only one on that list that cannot be settled internally. ## When it is asked for in a hurry **En corto** - Ask what it is for: the whole pack is not always needed. - Send the version in force and say explicitly that it is. - And request whatever you do not hold the same day: copies take time. > [!NOTE] > Which documents are required, how signing authority is evidenced and what formalities each resolution needs depend on the type of company and the country. **Your adviser or notary handles that**; the point here is that when it is asked for, nobody has to go hunting. **Is a scanned copy enough?** To get started usually; for signing, they will tell you the format required. **How often should powers be reviewed?** At least yearly, and whenever someone changes role. **What if an old set of minutes is missing?** Trace it through whoever formalised or holds it; start early. ## Ejemplos **A company reaches signing day and the signatory's power did not cover that transaction.** - Reviews powers yearly, noting what each covers and until when → The next signing does not hinge on discovering the scope that same morning. **Corporate documents sit in several places.** - Gathers everything in a company file → The handover is prepared in minutes. **They are requested four times a year and hunted each time.** - Keeps what was sent, with its date → You start from what was sent last time. **A corporate document is updated and nobody replaces it.** - Keeps each version with its date → The current one is provided. **Powers of attorney change and nobody says so.** - Reviews authority periodically → The record stays current. **A document is missing and it is discovered mid-transaction.** - Checks what is missing before starting → The gap closes with time to spare. --- --- id: KB-LE-017 url: https://app.codecontract.io/help/legal/the-file-behind-a-property-deal idioma: en categoria: sector-legal subcategoria: inmobiliario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-008, KB-CN-013, KB-CS-034] citadoPor: [KB-CS-011] --- # The file behind a property deal _What delays a signing is rarely the price: it is a document that expired while the deal was being negotiated._ **Responde a:** documents for a property sale · what the notary asks for · certificates expiring during a deal · preparing a property completion A property deal gathers documents from places that do not talk to each other: the registry, the town hall, the building's management, a technician, the bank, the owner. Each takes its own time and each stays valid for a different period, and that is what turns an agreed completion into a postponed one. ## Typical pieces and how fast they age | Piece | Who it comes from | How it ages | | --- | --- | --- | | Registry information | The land registry | Very fast: it reflects one moment | | Planning status of the property | The town hall | Slowly, unless changes are under way | | Technical certificates for the building | A technician | They carry their own validity | | Statement of debts to the building | The managing agent | Changes every quarter | | Documentation for installations and equipment | The owner or their maintenance firm | Inherited with the property | > [!IMPORTANT] > The first row throws anyone who has not lived it: **registry information describes an instant, not a permanent state**. Between requesting it and completing, new charges can appear, so the one that counts is the one from completion day, not the one that opened negotiations. What is asked for first is therefore usually what has to be asked for again at the end — and whoever discovers that at the notary's postpones a completion over something a phone call would have solved. ## How to order it so you are not always behind 1. **List everything needed on completion day, from the start** — Including what takes weeks and does not depend on you. 2. **Note for each piece who issues it and how long it takes** — That is what lets you ask in the right order rather than all at once. 3. **Ask for the slow things first and the fast-ageing ones last** — The opposite of the intuitive order, and the one that avoids repeats. 4. **And keep it all in one shared place with dates** — Five parties take part and none of them sees the others' email. > [!WARNING] > What postpones completion most often is not a missing document: it is **a document that was there and expired during the negotiation**. If a deal drags on for two months — and they do — what was requested at the start reaches the notary out of date. It is worth reviewing the whole file a week before the planned date, not the day before: whatever is missing can still be requested. ## What gets forgotten and shows up later **En corto** - Documentation for equipment and installations, which travels with the property. - What was agreed by email during negotiation and never made it into the contract. - And who keeps what of the contents, if it is not written down. > [!NOTE] > Which documentation is required in each deal, what formalities apply and what each party takes on is determined by your lawyer or notary, and varies by property type and region. **Ask at the start, not at the end**; here we only explain why the order of requests matters as much as the list. **Is it worth pulling the registry information at the start?** Yes, to know what you face. And again at the end, which is the one that counts. **Who should hold the file?** One person, even with five parties involved. Split up, something is always missing. **And for a rental?** Fewer pieces, same logic: the slow ones first, the expiring ones last. ## Ejemplos **A completion is postponed because registry information pulled two months earlier is stale.** - Requests the slow items first and the fast-ageing ones last, reviewing the file a week ahead → The date holds and whatever expires arrives freshly issued. **The deal folder is assembled from loose emails.** - Gathers everything in one file → What is there and what is missing is visible at once. **A document is missing on signing day.** - Checks what is missing in advance → The appointment is not repeated. **Each party works from their own copy.** - They share the same file → Everyone looks at the same thing. **Too much is shared when the folder goes out.** - Shares only what concerns each party → No information is handed over that should not be. **Years later the transaction must be evidenced.** - Keeps the file with its date → The answer comes from the archive. --- --- id: KB-LE-018 url: https://app.codecontract.io/help/legal/permits-for-foreign-workers idioma: en categoria: sector-legal subcategoria: extranjeria audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-013, KB-CR-016] citadoPor: [KB-LE-032] --- # Permits for foreign workers _Documents that belong to the person and not the company, with their own dates, and that stop the work if they lapse._ **Responde a:** tracking employees work permits · an employee's permit is expiring · immigration paperwork at the company · renewing a permit in time For a company employing foreign staff — or for the firm advising it — this is one of the few expiry dates with no slack: when a permit lapses, the person cannot keep working, and that is not a paperwork problem, it is a staffing problem on Monday morning. ## What makes it different from other expiries | Aspect | A company certificate | A person's permit | | --- | --- | --- | | Whose it is | The company's | The person's: they carry it | | Who can renew it | You | Only that person, with their own papers | | How long it takes | Days or weeks | However long the authority takes | | What happens if it lapses | A finding | They cannot work | > [!IMPORTANT] > The second row forces a different way of organising: **you cannot renew it, so the warning has to reach them and you at the same time**. An internal reminder achieves nothing if the person does not gather their papers in time; and warning with a month to go is late for many procedures. This is one of the few dates where a sensible margin is counted in months, and where it is worth asking how it is going rather than assuming it is under way. ## How to manage it without overreaching 1. **Store the validity date, not a copy of everything** — What you need to track is until when, not the personal detail. 2. **A double warning, months ahead** — To the person and to whoever handles staffing. 3. **And a clear contact point for questions** — Many will not ask so as not to expose themselves; make it clear who. > [!WARNING] > On what to keep: **this documentation contains sensitive personal data, and not everything the person shows you has to stay in your archive**. Checking and noting validity is not the same as keeping a full copy of everything. Keeping more here does not protect you more: it obliges you to safeguard information you do not need, and that is what gets asked about in a review. **What may be kept, and for how long, is for your adviser to settle.** ## What is worth planning for **En corto** - What happens to the role if the process drags: cover, reassignment, or waiting. - Who tells the client if that person was assigned to their service. - And that the process runs regardless of the employment relationship: it does not pause for holidays or workload. > [!NOTE] > Which permit types exist, what each requires, what deadlines apply and what duties you carry as an employer is determined by immigration and employment law in your country. **Your adviser or a specialist firm handles that**; here it is only about the date not arriving as a surprise. **Can I ask for a copy of the permit?** Checking it, yes; which copy you may keep, ask before filing. **What if the person does not renew in time?** That is an employment situation, not a documentary one: take advice before it happens. **Does the same control work for postings abroad?** No: that is a different matter on a different track. ## Ejemplos **A company finds three weeks out that a technician's permit expires and the process takes months.** - Warns the person and HR months ahead and follows up on progress → The process starts in time and the role is not left uncovered overnight. **A permit expires and the person keeps working.** - Records expiries per person → The warning arrives with room to renew. **Renewal is requested with two weeks to spare.** - Warns with the lead time the process actually needs → The real timeline is respected. **The documentation sits in the HR file and somewhere else.** - Gathers everything in the person's file → There is one place to check. **A client asks you to evidence a service's personnel.** - Checks each person's file → It is handed over without reassembling anything. **Somebody new joins and their documentation is missing.** - Checks what is missing before assigning them → Onboarding is resolved before day one. --- --- id: KB-LE-019 url: https://app.codecontract.io/help/legal/knowing-who-you-are-working-with idioma: en categoria: sector-legal subcategoria: compliance audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-009, KB-LE-004] citadoPor: [KB-LE-024, KB-LE-031] --- # Knowing who you are working with _In some activities, taking on a client means checking who they really are — and doing it before you start._ **Responde a:** client identification before starting · beneficial owner documentation · obliged entity what must i check · client acceptance file A new client arrives with an urgent job. Documentation gets requested «as we go», because nobody wants to open by raising objections. Three months later, when things get complicated, it turns out all that is known about the client is a trading name — and that whoever was signing did not hold the authority they claimed. **Beneficial owner** — The natural person actually behind it. Not the director who signs nor the company on the contract: whoever controls. Identifying them is precisely where a superficial check parts company with a real one. ## The four steps, and where people skip | Step | What is checked | The shortcut taken | | --- | --- | --- | | Who they are | Identity of the person or company | Accepting whatever the introduction email says | | Who really controls | The beneficial owner behind the company | Skipped once the structure has two levels | | Who may sign | Current powers and their scope | The power is read, its currency is not | | Where the money comes from | Source of funds, depending on the case | Assumed, because the client «is known to us» | > [!IMPORTANT] > The rule that avoids 90 % of the trouble is about timing, not content: **the check happens BEFORE starting, not alongside**. Once you have worked for a month, saying no is an expensive decision, which is why it almost never gets taken. Starting without checking is not gaining time: it is giving up the only window in which saying no is cheap. ## What makes the file useful later 1. **Keep what you checked and WHEN** — Undated, you cannot show it happened before starting. 2. **Note what you could not check, and why** — An explained gap is defensible; a silent one is not. 3. **Review whenever something changes** — Change of director, of ownership, of activity or of how they pay. 4. **And look again periodically even when nothing changes** — A four-year-old check describes a four-year-old company. > [!WARNING] > The most repeated blind spot is the long-standing client: **reviews are run on new clients and never on old ones**. The file of the client of eight years holds day-one documentation, and in those eight years they have changed owner, sector and billing country. A periodic sweep of the old portfolio turns up more than ten checks on new arrivals — and it is precisely the one nobody schedules, because there is nobody waiting on the other end of the phone. ## When something does not add up **En corto** - Write the doubt down as it arises, with a date: what is badly remembered is remembered late. - Separate «a document is missing» from «what I am being told does not add up»: different things. - And decide consciously, recording who decided to continue or to stop. > [!NOTE] > Who counts as an obliged entity, which checks correspond to each case, when there is a duty to report and what may NOT be told to the client is set by anti-money-laundering rules and their implementation. **Your adviser or compliance officer settles that, and it is not improvised**; here we cover the documentary side: check first, keep it dated, and look again. **Does this apply to my activity?** It depends on sector and transaction. That is exactly the question to take to your adviser beforehand. **How often do I review long-standing clients?** On a frequency you set, and whenever something relevant changes. **Can I start while completing the documentation?** It is the most expensive decision available. If taken, take it in writing and with a deadline. ## Ejemplos **A new client arrives with an urgent job and documentation is requested «as we go».** - Completes the check before starting and records the date on file → If saying no is required, it gets said while it is still cheap. **The file of an eight-year client holds day-one documentation only.** - Schedules a periodic sweep of the existing portfolio, not only of new arrivals → Changes of owner, sector or country stop going unnoticed for years. **Whoever signed for the client held a power of attorney that had been revoked.** - Checks that the power is current, not merely that it exists, and records the date → What was signed stands, because it is on record that the signatory could sign that day. **Work starts without checking who with.** - Runs the checks before accepting → The decision is taken with information. **There is no record of what was checked or when.** - Records the checks performed → The decision is explicable afterwards. **The information is checked once and never again.** - Schedules a periodic review → The record stays true. --- --- id: KB-LE-020 url: https://app.codecontract.io/help/legal/paperwork-of-a-company-that-changed-hands idioma: en categoria: sector-legal subcategoria: mercantil audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-016, KB-TZ-003] citadoPor: [KB-LE-023] --- # Paperwork of a company that changed hands _Documentary duties survive a change of owner; the archives often do not. That gap is inherited._ **Responde a:** we bought a company and dont have its paperwork · asked for documents predating the acquisition · transfer of records in a company sale · who answers for the old documentation A request arrives about something from six years ago and nobody from back then is left at the company. The business was bought, the systems were changed, an office was cleared out. Nobody did anything wrong at any of those steps — and the duty to be able to produce that material still exists, and is now yours. ## What changes and what does not | What to look at | Changes with the deal | Stays the same | | --- | --- | --- | | Who answers | Sometimes | **The duty to retain** | | Where the records are | Almost always | The retention period | | Who knows where things were | Yes, and it hurts most | What can be demanded of you | > [!IMPORTANT] > **The time to solve this is before signing the deal, and it takes an afternoon.** Afterwards, every month that passes takes with it another person who knew where something was. The question to put on the table is not «will you give us the archives?» —everyone says yes to that— but **«who retains them, in what format, for how many years, and who do we call when something is missing?»**, with the answer written into the agreement. ## If the deal is done and the gap exists 1. **Inventory what you do hold, by year** — Knowing where the hole starts is worth more than lamenting all of it. 2. **Ask the seller in writing** — Even if the answer is that they do not have it: the request and reply document you. 3. **Rebuild through third parties where possible** — Advisers, laboratories, insurers and clients keep their own copies. 4. **And record what is missing and why** — An explained gap is defensible; one discovered at an inspection is not. > [!WARNING] > The mistake that makes it worse is trying to paper over it: **recreating an old document to look period-correct**. It turns an inherited shortfall —explainable in two sentences and common to everyone— into something that is no longer a documentary gap. What holds your position in these cases is not having the paper, it is being able to recount what happened, with dates and with the requests you made to recover it. > [!NOTE] > Which retention duties transfer in each type of transaction —share sale, business unit sale, merger— and for how long, depends on the deal and the subject matter. **Your adviser settles that, and it is best resolved before signing**; here we cover the practical part that almost never makes it into the negotiation. **Can I require the archives from the seller?** It depends what was agreed. Which is why it is worth agreeing expressly. **What if the seller no longer exists?** Rebuild through third parties and document the attempt. **How much of the earlier period must be kept?** The same periods as if you had generated it yourselves. ## Ejemplos **A business is bought and six years later a request arrives about the earlier period.** - Inventories what is held by year and asks the seller in writing for what is missing → The gap is bounded and documented instead of being discovered whole in the reply. **The negotiation settles on «the archives will be handed over» and nothing more.** - Writes down who retains what, in what format, for how many years and who to call → The question five years from now has a specific addressee. **A whole year's documentation is missing and recreating it is floated.** - Documents what is missing, why, and what was requested to recover it → An explainable position is preserved instead of creating a different and worse problem. **The company changes hands and the archive is left half done.** - Inventories what exists before it disperses → You know what you have. **Access rights remain in the names of people who have left.** - Recovers access as soon as possible → What cannot be opened is not lost. **Nobody knows where the corporate documentation is.** - Gathers what is located into one file → There is one picture. --- --- id: KB-LE-021 url: https://app.codecontract.io/help/legal/the-firm-holding-its-clients-records idioma: en categoria: sector-legal subcategoria: despachos audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-003, KB-LE-011, KB-LE-026] citadoPor: [KB-LE-022, KB-LE-029, KB-LE-033] --- # The firm holding its clients' records _You hold the papers of two hundred companies and none is yours. That makes your archive the problem, not the solution._ **Responde a:** accountancy firm holding client records · how long do i keep a clients documents · adviser liability for the archive · what if i lose a clients documentation Your archive is the documentary memory of two hundred companies that are not you. That position has an obvious advantage —you hold everything— and a risk rarely sized properly: **a problem in your archive is not one problem, it is two hundred at once**. ## The four questions that reach a firm | Who asks | What they want | What answers it | | --- | --- | --- | | A client | Their documentation, now | Knowing what you hold of theirs and where | | A departing client | Everything of theirs | A procedure, not a negotiation | | An authority | Something about one client | That client's file, not the firm's | | **The client, years later** | **Something from when they were a client** | **The retention policy you set** | > [!IMPORTANT] > **The question you must be able to answer at any time is «what do I hold of this client and why do I hold it?».** It is not about tidiness: it is what separates custody from hoarding. A firm that keeps everything just in case carries more risk, not more service — every extra document is one to protect, justify and eventually delete, and multiplied by two hundred clients it becomes the firm's largest exposure. ## What is worth settling, and almost nobody has 1. **What is kept per client and for how long** — Written once and applied to all, not decided case by case. 2. **Who in the firm may open what** — «Everyone sees everything» stops being sustainable past a few clients. 3. **What is handed over when a client leaves** — In what format and by when. Before the first one leaves. 4. **And what happens to a client who disappears** — The awkward case, and commoner than it sounds. > [!WARNING] > The specific risk of this position, and the worst to handle: **the client believes you hold everything, and you believe they hold their own**. Both are wrong simultaneously. They kept no copy because «the firm has it» and you kept only what your engagement required. When a question arrives about something outside that engagement, nobody has it. Stating in writing what you keep and what you do not, at the outset, avoids that entire conversation. > [!NOTE] > What documentation a firm must retain, for how long, what confidentiality and data-protection duties apply and what must be handed over on ending an engagement depends on the subject matter, professional rules and data-protection law. **Your professional body or adviser settles that**; here we cover the organisational part that decides whether you can answer. **Do I return everything to a departing client?** Theirs, yes — and have the procedure written before you need it. **Can I keep a copy?** It depends on the subject and applicable period. Set it once for everyone. **What if the client says they hold nothing?** Which is why it pays to state at the outset what you keep and what they must. ## Ejemplos **A client asks for their documentation and what is held has to be reconstructed.** - Keeps an index per client of what is retained and why → The handover is prepared in hours rather than days. **The firm keeps everything «just in case» for two hundred clients.** - Sets a retention policy and applies it to everyone alike → Exposure falls without losing anything that must be held. **A client leaves and the handover is negotiated on the fly.** - Has it written down what is handed over, in what format and by when → Departure is a procedure rather than an argument. **A question arrives about something never within the engagement and nobody holds it.** - States at the outset what the firm keeps and what the client must keep → Each side retains their own, knowingly. **The whole team can open every client's folders.** - Restricts who opens what according to the engagement they work on → Sensitive material stops being within reach of those who do not need it. **A client disappears and their documentation sits ownerless in the archive.** - Decides beforehand what happens in that case and documents it → The archive stops accumulating files nobody can claim or delete. --- --- id: KB-LE-022 url: https://app.codecontract.io/help/legal/your-adviser-has-the-papers-and-you-dont idioma: en categoria: sector-legal subcategoria: fiscal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-021, KB-TZ-003, KB-LE-015] citadoPor: [KB-LE-023] --- # Your adviser has the papers and you don't _Delegating the admin does not delegate the duty: if you are asked, you are the one asked — and the answer sits in another office._ **Responde a:** my accountant holds all my documentation · asked for papers my adviser holds · what documentation should i keep myself · delegating bookkeeping and liability It is the commonest arrangement in a small company: **the firm handles everything**. It works perfectly for years, until the day someone asks about a document on a Friday afternoon and the answer is «our accountant has that» — a sentence that sounds like an excuse even when it is true. ## What changes and what does not when you delegate | What to look at | Handled by the adviser | Still yours | | --- | --- | --- | | The admin and the deadlines | Yes | — | | The technical knowledge | Yes | — | | **The obligation** | **No** | **Yes, always** | | Being able to produce it on request | Sometimes | **Yes, and that is what fails** | > [!IMPORTANT] > **You can delegate who does it; you cannot delegate who answers.** It is the line almost nobody sees clearly until they cross it. Your adviser represents you and works well, but the request arrives in your name, the deadline runs for you, and if the adviser is on holiday the deadline runs anyway. Keeping a copy of what goes out in your name is not distrust: it is that you are the addressee of the question. ## The minimum worth holding in your own house 1. **A copy of what is filed in your name** — Each filing, when it is made, not when you ask for it. 2. **The contracts and documents underpinning the business** — Those are yours at source, not a product of the bookkeeping. 3. **An index of what sits at the firm** — So you can say where it is even without holding it. 4. **And knowing who to call there, not just the switchboard** — A deadline runs in August too. > [!WARNING] > The moment this stops being theoretical: **when you change adviser or the adviser closes**. That is when you discover years of documentation existed in one place only, that the handover depends on the goodwill of someone you may be parting from badly, and that rebuilding what is missing costs more than keeping it would have. It is the same problem as changing systems, and it is prevented the same way: by keeping a copy while things are going well. > [!NOTE] > What documentation a company must retain directly, for how long, and what liability survives delegation depends on the subject and the applicable rules. **Your adviser settles that — ask them, it is a ten-minute conversation**; here we explain why a copy is worth having even when the answer is that they already keep it. **If my adviser holds it, is that enough?** To operate yes; to answer on the spot, keep a copy. **Do I have to keep the same as them?** Not all of it: what underpins your business and what is filed in your name. **What if I change adviser?** That is when it shows. Hence the copy while things are going well. ## Ejemplos **A request arrives on a Friday and the firm is closed until Monday.** - Keeps a copy of what is filed in their name, as it is filed → The response starts on Friday rather than Monday. **You change adviser and years of documentation exist only in their office.** - Keeps a copy while the relationship is going well → The handover stops depending on anyone's goodwill. **A client asks for an old contract and nobody knows whether the company or the firm holds it.** - Maintains an index of what is where → You can say where it is even without holding it. **A deadline runs in August and only the firm's switchboard number is known.** - Records who to call there, with a name and direct contact → The deadline is met even in holiday season. **The company assumes the firm also keeps its commercial contracts.** - Separates what is theirs at source from what the bookkeeping produces → The documents underpinning the business are where they should be. **The firm closes on retirement with a month's notice.** - Requests and keeps periodic copies instead of waiting for the handover → The closure is a change of supplier rather than a loss of memory. --- --- id: KB-LE-023 url: https://app.codecontract.io/help/legal/changing-firms-and-taking-the-archive idioma: en categoria: sector-legal subcategoria: contractual audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-022, KB-TZ-009, KB-LE-020] citadoPor: [KB-LE-013] --- # Changing firms and taking the archive _The change is decided in an afternoon and the handover takes months. Whatever you do not request before announcing it costs double after._ **Responde a:** changing accountants how to get my documentation · handover of records between firms · my old firm wont hand over my papers · what to request before switching adviser The decision to switch is usually taken quickly and for reasons that are not documentary: price, service, one error too many. The handover, by contrast, is slow, quiet work that starts badly if done in the wrong order — **and the wrong order is announcing first and requesting afterwards**. ## The order that works 1. **Request a copy of what they hold of yours, before saying anything** — It is a normal request from an active client, and is treated as such. 2. **Check what is missing against your index** — If you have no index, that is the first job. 3. **And only then announce the change** — With the copy already in your house, the handover stops being leverage. 4. **Put the formal handover in writing** — What is delivered, in what format and when. > [!IMPORTANT] > **Requesting your documentation while still a client is not a manoeuvre: it is elementary prudence, and the whole sector knows it.** After the notice, the same request competes with the diary of someone who has just lost a client. It is not bad faith —it is priority— but the result is the same: weeks of delay precisely when the new adviser needs everything to start. ## What to ask for, and it is not «everything» | What | Why it matters | | --- | --- | | What was filed in your name, by year | It is what will be demanded of you | | The original documents you provided | They are yours and sometimes there is no copy | | The calculations or criteria they applied | Without them the new adviser starts from zero | | **And in what format you get it** | **A box of paper is not a handover** | > [!WARNING] > What is most often lost in a switch is not documents: **it is the reasoning**. Why something was done a particular way, what was agreed at the time with an authority, what is peculiar about your case. That lives in the head of whoever handled you and is in no folder. A one-hour meeting between outgoing and incoming adviser is worth more than half the archive — and it must be requested while the relationship is still cordial. > [!NOTE] > What a professional must hand over on ending an engagement, within what period and what may be withheld depends on professional rules and on what was agreed. **If the handover becomes difficult, your new adviser or professional body settles that**; here we explain the order that avoids reaching that point. **Can they withhold my documentation?** It depends on professional rules and what was agreed. Ask before it becomes a problem. **What format should I ask for?** One that can be used. A box of paper with no index is half a handover. **Is a handover meeting worth it?** It is the most easily lost and cheapest thing to preserve. Ask for it. ## Ejemplos **The change is announced and only then is the documentation requested.** - Requests a copy of everything while still an active client → Delivery arrives in days instead of competing with the diary of someone who lost a client. **A box of paper with no index arrives and the new adviser cannot begin.** - Agrees the handover format before it is executed → The new adviser can work from day one. **The reasoning behind why something was done a certain way is lost.** - Requests a handover meeting between outgoing and incoming adviser → What lived in one head moves into the company. **Original documents the company provided years ago are missing.** - Compares what is received against their own index of what was handed over → What is missing is spotted while it can still be claimed. **The handover is agreed verbally and nobody knows what remained outstanding.** - Puts in writing what is delivered, in what format and when → The handover can be closed and treated as complete. **A request arrives about a year from the previous arrangement.** - Keeps what was filed in their name by year, not only the recent → The answer does not depend on a firm they no longer work with. --- --- id: KB-LE-024 url: https://app.codecontract.io/help/legal/the-supplier-sent-a-questionnaire idioma: en categoria: sector-legal subcategoria: esg audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-019, KB-LE-004] citadoPor: [KB-LE-025, KB-LE-026] --- # The supplier sent a questionnaire _Forty questions from a client who does not negotiate, with a deadline and nobody to ask what they mean._ **Responde a:** client sent a supplier questionnaire · how to answer a sustainability questionnaire · asked for policies i do not have · supplier onboarding questionnaire An email arrives from your best client with a forty-question questionnaire, a two-week deadline and a note saying it is a condition of remaining a supplier. **You did not negotiate it, it is not in the contract and there is nobody to argue with** — the person who sent it did not write it either. This is now one of the commonest ways documentary demands reach a mid-sized company: not through a rule, but through a customer. ## What a questionnaire actually asks | Kind of question | What they want to know | What it costs you | | --- | --- | --- | | Do you have a policy on X? | Whether the document exists | Little, if it exists | | Can you evidence it? | Whether there is something to show | Quite a lot, if it was not kept | | How many cases were there? | Whether you keep records | A great deal, if it was never counted | | **And your suppliers?** | **Whether you pass the same on** | **The dearest of all** | > [!IMPORTANT] > **A questionnaire is not answered, it is built once and reused.** That is the difference between this position being an annual problem or an afternoon. The first costs weeks because everything has to be hunted down; the second costs little because the answers already exist and only the form changes. What makes a questionnaire expensive is not the questions: it is that every client asks them differently and every time it starts from zero. ## How to make it reusable 1. **Keep the answers, not just send them** — With the date and the document that backed each one. 2. **Know where the always-attached items live** — It is nearly always the same eight or ten documents. 3. **Note down what you did not have** — That list is the year's agenda, and it comes free. 4. **And review before the next one, not during** — The next questionnaire is coming. It always comes. > [!WARNING] > The temptation in this position is **answering yes to everything so as not to lose the client**. It is understandable: there is a contract at stake and a short deadline. The problem is that a questionnaire is not a sales conversation — it is filed, it is signed, and in some cases it is verified afterwards with a visit or a request for evidence. An answer you cannot back up is worse than «we do not have this yet, we will by June», which many clients accept without fuss. > [!NOTE] > What requirements a client may impose, which of them come from rules that apply to them and reach you by contract, and what signing a declaration of this kind entails **depends on the sector, the country and the contract, and is settled by your adviser**. Here we cover the operational part: how to answer without starting from scratch each time and how to back up what you say. **Can I refuse to answer?** You can, and it usually costs the client. Answering honestly tends to work better than either alternative. **What do I do about what I do not have?** Say so, with a date if there is one. It is acceptable far more often than it seems. **Is last year's answer usable?** As a starting point, always. As an unreviewed answer, no. ## Ejemplos **A client sends a questionnaire with a two-week deadline.** - Keeps previous answers and what backed them → You start from what was already answered rather than zero. **The always-attached documents live in five folders.** - Gathers the company file in one place → Attaching stops being half the job. **Yes is answered to something that cannot be backed up.** - Shows which document backs each answer → You answer what can be evidenced. **The client later asks for evidence of what was declared.** - Keeps what was sent, with its date → You show exactly what was declared at the time. **Every client asks the same things on a different form.** - Reuses the same documentary base for each request → The third questionnaire costs an afternoon. **What was missing last year is still missing this year.** - Records what was left outstanding → The list of gaps gets worked through during the year. --- --- id: KB-LE-025 url: https://app.codecontract.io/help/legal/passing-the-requirement-down-the-chain idioma: en categoria: sector-legal subcategoria: tic audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-024, KB-LE-003] citadoPor: [KB-LE-026] --- # Passing the requirement down the chain _Your client makes demands of you and you depend on four suppliers who have never heard of them. You are what holds the chain up._ **Responde a:** passing client requirements to my suppliers · sub-processors and documentation · my supplier does not meet what is asked of me · controlling the supplier chain You signed with a demanding client, and inside that signature are commitments that **do not depend on you but on the people you buy from**: whoever hosts the data, whoever performs part of the service, whoever sends the technicians. Yours is the position holding the chain up, and it is also the only one that can be chased from both sides at once. ## The sum that does not add up on its own | What is required of you | Who it depends on | Who answers | | --- | --- | --- | | How you handle the information | You | You | | Where it is hosted | Your supplier | You | | Who may access it | Both | You | | **What your supplier's supplier does** | **Nobody you know** | **You** | > [!IMPORTANT] > **The rule that avoids 90% of this position's problems is requiring downwards at least what is required of you — and doing it when you contract, not when you are asked.** What is not in your contract with the supplier you will not obtain later: at that point you are a client asking a favour, and the favour has a price or a polite refusal. ## What to hold for each supplier touching the client's work 1. **What you required of them, in writing** — And checking it covers what was required of you. 2. **What they have provided and when** — With dates, because what expires here expires upwards. 3. **Who they subcontract to** — Asking at contracting is normal; asking afterwards is an incident. 4. **And what happens if something changes** — A supplier that moves premises or owners affects you before they tell you. > [!WARNING] > The moment this position hurts is **a client audit that goes one level deeper**. They no longer ask what you do: they ask about your suppliers, by name. If that question is met with a list and current documents, it is a formality. If it is met with «I would have to ask», the finding is no longer about the supplier: it is about you, because what has been demonstrated is that you did not know. > [!NOTE] > What duties you carry over your suppliers depending on the service and the information, what must be agreed contractually and what regime applies to each link **is settled by your adviser**, and varies greatly between sectors and countries. Here we cover the organisational part: how to ask for it, how to keep it current and how to answer for the whole chain without phoning anyone. **Must I require of my supplier what is required of me?** It is what closes the gap. How it is framed is for your adviser. **What if my supplier is far larger than me?** It happens often, and then the leverage is choosing well at contracting. **How often should this be reviewed?** Better than reviewing: be told when something falls due. Reviewing stops happening. ## Ejemplos **The client audits and asks about your suppliers by name.** - Keeps a file per supplier with their documentation → You answer with a list instead of an enquiry. **A supplier's document expires and affects what you promised.** - Warns about third-party expiries as it does your own → The gap closes before the question arrives. **Nobody knows who your supplier subcontracts to.** - Records the chain declared by each supplier → The chain is known before it is asked about. **What was required of the supplier was agreed verbally.** - Keeps what was agreed alongside the supplier's file → What is enforceable is demonstrable. **Each department contracts suppliers on its own.** - Gathers supplier files in a single place → There is one picture of the chain, not four. **Chasing suppliers for documentation is done by hand.** - Requests and chases automatically → The chain stays current without dedicating a person. --- --- id: KB-LE-026 url: https://app.codecontract.io/help/legal/when-the-requirement-comes-from-another-country idioma: en categoria: sector-legal subcategoria: internacional audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-024, KB-LE-025, KB-LE-027, KB-LE-031, KB-LE-032] citadoPor: [KB-LE-021] --- # When the requirement comes from another country _You are asked for a document that in your country has another name, no issuer and no exact equivalent. The clock runs anyway._ **Responde a:** asked for a certificate that does not exist here · foreign parent company requesting documentation · equivalence of documents between countries · foreign client asking for different paperwork The request comes from a parent company, a client or a group in another country, and it carries a list written for their reality: names of documents issued there by a specific body, formats not used here, and certificates that **simply do not exist under that name in your jurisdiction**. Whoever sent it does not know that, and often cannot: to them the list is «the normal one». ## The four kinds of mismatch, and they are not solved alike | The mismatch | Typical example | What resolves it | | --- | --- | --- | | Same document, another name | A certificate called something else here | Explaining it once, in writing | | Document with a different scope | Covers more or less than theirs | Saying what yours covers | | Issued by someone else here | A different authority or body | Saying who issues it and why | | **It does not exist here** | **No equivalent** | **Proposing what stands in for it** | > [!IMPORTANT] > **The work in this position is not obtaining the document: it is translating the requirement — and that translation must be written once and kept.** The same request will come back next year, with a different person on the other side and probably in the same format. Whoever has written down «what you are asking for is called this here, is issued by this body and covers this» answers in an hour. Whoever has not explains it from scratch every time, and differently every time. ## How to answer a list that does not fit 1. **Match point by point whatever does exist** — Most of the list usually has a clear equivalent. 2. **Name what is called something else here** — And attach it, so the equivalence is visible. 3. **Explain what does not exist, never leave it blank** — An unexplained gap reads as a breach. 4. **And keep that explanation as a document of your own** — It is an asset reused for years. > [!WARNING] > The mistake that costs most time is **leaving blank what cannot be supplied**. On the other side someone is working through a list of boxes, with no context about your country and with their own deadline; an empty box is a breach, and a box with two lines explaining why that does not exist here is a footnote. It is literally the same situation with two different outcomes, and the difference is two lines written in time. > [!NOTE] > Which document in your jurisdiction is equivalent to a foreign one, what standing it has abroad and whether it needs sworn translation, legalisation or an apostille **is settled by your adviser**, and depends on the destination country and the use. Here we cover the organisational part: how to answer a list that does not fit and how not to rebuild the answer every year. **Must I translate everything I send?** It depends on the use and the destination, and your adviser settles that. Ask before translating forty pages. **What do I do about what does not exist here?** Explain it and propose the equivalent. It is almost always accepted. **Is last year's answer usable?** This is precisely the case where it is most usable, if it was kept. ## Ejemplos **A list arrives naming documents that do not exist here.** - Keeps the explained equivalence alongside the documents → The next request is answered in an hour. **What cannot be supplied is left blank.** - Allows attaching the explanation to each point → The gap reads as a footnote rather than a failure. **The same request arrives yearly and is rebuilt from scratch.** - Keeps what was sent, with its date and context → You start from the previous answer. **Each subsidiary answers in its own way.** - Gathers the group's documentation in one place → The parent receives comparable answers. **Forty pages get translated that nobody asked to be translated.** - Keeps exactly what was requested and its scope → You translate what is needed rather than what was sent. **The foreign contact changes and it all has to be explained again.** - Keeps the explanation as a reusable document → A change of person does not restart the work. --- --- id: KB-LE-027 url: https://app.codecontract.io/help/legal/handing-over-the-same-thing-every-quarter idioma: en categoria: sector-legal subcategoria: bancario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-016, KB-LE-014] citadoPor: [KB-LE-026] --- # Handing over the same thing every quarter _The same list, four times a year, always in a rush and always hunted down in the same different places._ **Responde a:** documentation the bank requests every quarter · facility renewal documentation · asked for accounts and guarantees again · organising what the lender asks for Whoever finances you comes back on a fixed cycle: at renewal, at review, at year end. **The list is nearly always the same and is nearly always hunted from scratch**, because months pass between requests, the person asking changes and so does the person answering. It is probably the most repetitive documentary work a mid-sized company does, and the least organised precisely because it is repetitive. ## Why it costs the same every time | What is asked for | Where it usually sits | Why it takes time | | --- | --- | --- | | Accounts and filings | With the accountants | They have to be asked | | Corporate documents | In an old folder | Nobody remembers which | | Policies and guarantees | With whoever signed them | Who may have left | | **The same as last year** | **In a sent email** | **Nobody filed it as an archive** | > [!IMPORTANT] > **What turns this into an afternoon rather than a week is keeping what was SENT, not only what was received.** It is a small, counter-intuitive shift: the folder you need is not the one with the company's documents, it is the one with «what we sent last time and when». With that in front of you the next request is resolved by comparison; without it, it is resolved by reconstruction — the same work already done three months ago. ## How to stop starting from zero 1. **Keep each submission as a dated file** — What was asked, what was sent and to whom. 2. **Know where the always-included items live** — It is nearly always the same six or eight documents. 3. **Know which of them expire** — And find out before they are asked for, not when they are. 4. **And do not let it depend on one person** — It is the work that concentrates most on someone who is one day on holiday. > [!WARNING] > The request never arrives at a calm moment: **it arrives when a transaction is under way and there is a deadline**. That detail changes the calculation. Gathering the documentation is not hard; it is that it is asked for exactly when there is least room, and a week's delay on a renewal or a drawdown has consequences that are not documentary. All the value of having it in order is collected on those specific days. > [!NOTE] > What documentation a lender may require, at what intervals and what is entailed by what is signed on submission **depends on the facility and the contract, and is settled by your adviser**. Here we cover the organisational part: how not to redo the same work four times a year and how to know what was submitted last time. **Is last quarter's submission usable?** As a starting point always; as an unreviewed answer, almost never. **Can I ask my accountants to keep it ready?** Yes, and it is worth agreeing in advance rather than in the week of the request. **Is it worth setting up for only four times a year?** Four times a year is exactly the frequency at which nobody remembers how it was done. ## Ejemplos **The lender asks for the same list and it is hunted from scratch.** - Keeps each previous submission with its date and contents → You start from what was sent last time. **Documents are split between the accountants, management and an inbox.** - Gathers the company file in one place → The submission stops depending on three people. **A corporate document expires and it is discovered with the request pending.** - Warns about expiries before they happen → Renewal happens with room to spare. **The person who always prepared it is on holiday.** - Keeps the file accessible to the team → The request does not wait for someone to return. **Nobody knows exactly what was submitted at the last renewal.** - Stores what was sent as a file rather than an email → You can compare instead of reconstruct. **The request arrives with a transaction under way and a short deadline.** - Keeps documentation current continuously → The deadline is met without stopping everything else. --- --- id: KB-LE-028 url: https://app.codecontract.io/help/legal/opening-your-books-in-order-to-sell idioma: en categoria: sector-legal subcategoria: ma audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-008, KB-LE-016] citadoPor: [KB-LE-029] --- # Opening your books in order to sell _The price is agreed on a figure and adjusted by whatever surfaces. Everything you do not find, the buyer will._ **Responde a:** preparing for due diligence · documentation requested when selling a company · tidying up records before a sale · the buyer finds things we did not know about You have agreed a price and from there a review begins: contracts, employment, licences, property, litigation, insurance. **You do not run that review and you do not control it**, and its outcome is not an academic report — it translates into price reductions, into warranties you must give, or, if something large enough surfaces, into the deal collapsing. ## What is actually being measured | What they find | How it reads | Effect | | --- | --- | --- | | Everything in order | A well-run company | Confidence, and fewer questions | | One document missing | An oversight | It is requested and things move on | | Many missing | **You do not know what you hold** | **Everything gets scrutinised** | | **Something you concealed** | **A trust problem** | **Collapse or full renegotiation** | > [!IMPORTANT] > **What costs most in a review is not what is wrong: it is what cannot be found.** A contract with an awkward clause gets valued and discounted once. A contract nobody can locate forces the worst possible assumption about its contents, and that worst case gets discounted too. Same company, two different prices, and the difference is the archive. ## What to do before opening the door 1. **Review it yourselves first, using the buyer's list** — The lists are fairly standard. Ask for it or anticipate it. 2. **Find the gaps and close what can be closed** — An unsigned contract can be signed; in three months, it cannot. 3. **And whatever cannot, declare it first** — What you disclose gets valued; what they find gets penalised. 4. **Prepare how it is handed over** — Organised, controlling who sees what, with a trail of what was shared. > [!WARNING] > The asymmetry in this position is total and worth keeping in mind: **for the buyer this is a process they have run twenty times, and for you it is the first and probably only one**. They have lists, templates and dedicated people; you have to keep trading while you answer. Starting to tidy up when the first request arrives is starting late — and that asymmetry costs real money, not pride. > [!NOTE] > What exactly is reviewed in a transaction, what representations and warranties are signed and what consequences they carry **depends on the deal and the contract, and is settled by your adviser and your lawyer**. Here we cover the organisational part: how to arrive with the archive in shape and how to hand it over without losing control of what is shared. **When should I start tidying up?** Before there is a buyer. It is the only moment when it costs nothing. **Can I withhold something?** Your lawyer decides that, and the consequences of concealment are not documentary. **Is a shared folder enough?** To start. What is also needed is knowing who has seen what. ## Ejemplos **The buyer sends a long list and it has to be hunted across many places.** - Gathers the company's documentation in one file → You answer in blocks rather than by discovery. **A contract turns up that nobody can locate.** - Shows what is missing before the review opens → The gap closes while it still can. **A folder is shared and nobody knows who has seen what.** - Controls access and leaves a trail of what was viewed → The handover is orderly and verifiable. **Each department sends theirs in a different format.** - Centralises what is handed over in one place → The buyer receives a coherent set. **A key document sits in the mailbox of someone who has left.** - Keeps documents outside personal inboxes → One person leaving does not take the archive. **The review drags on and nobody knows what is outstanding.** - Shows the status of what was requested and delivered → The process runs on a list rather than on emails. --- --- id: KB-LE-029 url: https://app.codecontract.io/help/legal/coming-in-to-rebuild-someone-elses-archive idioma: en categoria: sector-legal subcategoria: concursal audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-028, KB-LE-021] citadoPor: [KB-LE-008] --- # Coming in to rebuild someone else's archive _You arrive at a company where people are leaving and systems are being switched off. Every week there is less to rebuild and fewer people to ask._ **Responde a:** rebuilding a company's documentation · access to systems of a distressed company · which documentation to secure first · people leaving and taking the knowledge You walk into a company going through a difficult moment and your job starts with finding out what exists. **Nobody is going to tell you the whole of it**: whoever knew has left or is leaving, access is in the names of people no longer there, and the information sits across systems somebody might stop paying for next month. It is the position with the most urgency and the least context of them all. ## What degrades, and how fast | What exists | How long it lasts | What to do first | | --- | --- | --- | | The people who know | Weeks | Ask and write it down | | Personal access rights | Until they leave | Recover them now | | Contracted services | Until non-payment | Inventory them | | **Paper in the office** | **Until it closes** | **Locate it early** | > [!IMPORTANT] > **The first task is not organising, it is securing.** It is counter-intuitive for anyone coming from archive work: the temptation is to start classifying, and the urgent thing is the opposite — putting beyond reach of loss whatever is about to disappear, even if it stays untidy. A messily exported mailbox can be classified in three months; an account closed for non-payment is not recovered by any later effort. ## The order that works in the first weeks 1. **Inventory where the information lives** — Which services, which machines, which cabinets, and in whose name. 2. **Secure access before contents** — What cannot be opened may as well not exist. 3. **Talk to whoever is leaving, before they leave** — It is the shortest window and the most informative. 4. **And record what was found and what was not** — A documented absence is a finding; an undocumented one is a doubt. > [!WARNING] > The commonest mistake in this position is **assuming information will be where it ought to be**. It rarely is: what matters usually lives on one particular person's machine, in a personal mailbox, or in a service paid for with a card that no longer works. Asking «where is this actually?» of the people still there, during the first fortnight, yields more than any orderly search of the official locations. > [!NOTE] > What powers you hold to access information, what must be retained by law, for how long, and what duties apply to personal data of employees and customers **is determined by the applicable rules and your engagement, and settled by your adviser**. Here we cover the organisational part: how to secure what is degrading and how to evidence what could not be found. **Where do I start?** With access and with people. Paper and files last longer. **What about what does not turn up?** Document the search and the outcome. A proven absence has value. **How much time do I have?** Less than it seems: it is measured in weeks and set by when people leave. ## Ejemplos **Information is scattered across mailboxes and personal machines.** - Gathers what is recovered into a common file → It stops depending on who held what. **The person who knew the archive is leaving in a fortnight.** - Allows collecting and storing what they provide before they go → The knowledge is captured before they leave. **A key document does not turn up and no search is on record.** - Records what was requested and what was obtained → The absence is documented as a finding. **Documentation must be requested from dozens of third parties at once.** - Sends the requests and chases automatically → The work does not scale with the number of contacts. **Nobody knows what has already been reviewed and what has not.** - Shows the status of what was requested and received → Progress is visible without status meetings. **What is recovered is stored with no control over who can see it.** - Restricts access according to who needs to consult it → Sensitive information is not within everyone's reach. --- --- id: KB-LE-030 url: https://app.codecontract.io/help/legal/proving-it-with-whatever-you-kept idioma: en categoria: sector-legal subcategoria: arbitraje audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-002, KB-LE-013] citadoPor: [KB-LE-031] --- # Proving it with whatever you kept _The argument is no longer who is right: it is who can show it. And there is a deadline, and no second round._ **Responde a:** what documentation to submit in arbitration · proving what was agreed by email · deadline to submit documents · cannot find the emails from that project By this point there is no room left to explain: there is a deadline, submissions must be made, and **what is submitted is what there will be**. The whole relationship —two years of emails, calls, meetings, decisions taken on the hoof— is reduced to whatever can be put on the table by a date. And what can be put there does not depend on how you worked, but on how you filed while working. ## What the submittable material consists of | What there was | Where it usually sits | If it is not there | | --- | --- | --- | | The contract | It gets found | Rarely missing | | What was agreed later | In scattered emails | **In practical terms it never existed** | | What was discussed | In memory | It cannot be submitted | | **What was warned and ignored** | **In an email, if one was sent** | **It weighs most and is missing most** | > [!IMPORTANT] > **Almost every change to a commercial relationship is agreed by email, and almost no email is filed as what it is: a contract amendment.** The original contract lives in a folder and is always found; the six emails that changed the scope, the dates or the price live in specific people's inboxes, some of whom have left the company. In a procedure, those six emails weigh more than the contract. ## What can be done beforehand, and only beforehand 1. **File later agreements where the contract lives** — An email that changes something is part of the contract, not correspondence. 2. **Put warnings in writing** — «We did tell them» only counts if it was said on a channel that leaves a trace. 3. **Do not let it depend on personal inboxes** — People leave and their mail is closed. It is the commonest loss. 4. **And retain beyond the end of the project** — Procedures begin once the project has already been archived. > [!WARNING] > The commonest discovery when preparing a procedure is **that the person who handled it left and their mailbox was closed**. Nobody decided it: the normal leavers policy was applied. With it went the conversations explaining why what was done was done, and what remains is a contract that does not reflect what was actually agreed. That loss cannot be repaired, and it happens through an administrative decision taken months earlier without this in mind. > [!NOTE] > What documentation is admissible as evidence, within what deadlines it must be submitted and what weight each kind of communication carries **is determined by the rules governing the procedure and settled by your lawyer**. Here we cover what comes before: how to arrive with what is needed already filed, because at that point nothing more can be generated. **Does an email count as proof of an agreement?** Its weight is for the procedure to decide; what is certain is that it counts for nothing if it does not exist. **How long do I keep a finished project's records?** Longer than the project lasts. Your lawyer sets the exact period. **What if the person who handled it has left?** Which is why the archive cannot live in their inbox. It is the commonest loss. ## Ejemplos **Later agreements live in scattered emails.** - Files each agreement alongside the contract it amends → What was agreed later is submitted with what was agreed before. **The person who ran the project left and their mailbox was closed.** - Stores documentation outside personal inboxes → A departure does not take the relationship's history. **Submissions are due and half the relationship is missing.** - Gathers the complete file for each client or project → Preparation is a review rather than a search. **«We did warn them» is nowhere on record.** - Keeps sent communications with their dates → The warning is shown rather than recounted. **The project was archived and its documentation purged.** - Applies retention set with legal periods in mind → What is needed years later still exists. **Each department keeps its part of the relationship separately.** - Centralises the file in one place → The complete account exists in one location. --- --- id: KB-LE-031 url: https://app.codecontract.io/help/legal/receiving-a-visit-with-no-notice idioma: en categoria: sector-legal subcategoria: competencia audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-030, KB-LE-019] citadoPor: [KB-LE-026] --- # Receiving a visit with no notice _They arrive in the morning, unannounced, and they choose what to take. The only thing you can prepare is what comes before._ **Responde a:** what to do if inspectors arrive unannounced · they take copies of emails and documents · what can be prepared before an inspection · who handles an inspection visit One day they turn up without an appointment and with an order. **There is nothing to prepare that day**: what exists is what exists, and what they take is their decision. Everything that can be done about this situation happens beforehand —months or years— and consists of two very different things that tend to get confused: knowing what you hold, and your people knowing what to do when the buzzer goes. ## What is decided at each moment | When | What can be decided | Who decides it | | --- | --- | --- | | Years before | What is kept and where | You | | Months before | Who knows what to do | You | | That day | How it is handled | Whoever is on reception | | **What they take** | **Nothing** | **They do** | > [!IMPORTANT] > **The most consequential decision in all of this is taken, unknowingly, by whoever opens the door.** That is not a figure of speech: the first half hour sets the tone, determines whether the right people are alerted in time, and decides whether somebody starts doing things on their own initiative with good intentions. Having a simple instruction —who to call, what to do meanwhile, what not to touch— is worth more than any amount of later documentary preparation. ## What can actually be ready 1. **Knowing what information exists and where** — Not to hide it: to be able to accompany and know what is taken. 2. **A written instruction on what to do, and short** — Half a page. A long one is neither read nor remembered. 3. **A record of what they take** — What is copied, from where and from what dates. It is needed afterwards. 4. **And alerting the right people immediately** — Your lawyer must be involved in the first hours, not the next day. > [!WARNING] > There is an instinctive reaction to plan for precisely because it is instinctive: **starting to tidy, delete or move things on hearing the news**. It comes from an employee's good intention to help, not from a management decision, and it turns a manageable situation into a completely different and far worse one. The written instruction exists above all to prevent that, which is why it must be written beforehand and known by more people than the board. > [!NOTE] > What powers each kind of inspection has, what rights and duties you have during the visit, what may be withheld and how the proceedings are documented **is determined by the applicable rules and settled by your lawyer**, and there are important differences between subject matters. Here we cover the organisational part: knowing what information exists and having in writing what your people do. **Can I prepare anything on the day?** Practically nothing. Everything useful is done beforehand. **Who should handle it?** Whoever is designated, and everyone should know who to alert. **Should what they take be recorded?** Yes, in detail. It is the basis for everything that follows. ## Ejemplos **They arrive unannounced and nobody knows who to call.** - Keeps the procedure written down and accessible → The first half hour is handled properly. **Nobody knows for certain what information exists or where.** - Keeps the archive organised and locatable → You can accompany them knowing what is being discussed. **No record remains of what was taken.** - Allows recording what was handed over, dated and in detail → The proceedings are documented from day one. **An employee starts moving things on their own initiative.** - Has the instruction clear and known beforehand → The instinctive reaction is replaced by a procedure. **Information is scattered across personal machines.** - Centralises documentation off individual machines → What exists is known without opening each computer. **What happened that day has to be reconstructed afterwards.** - Keeps the record of the visit and what was provided → A file of what occurred exists. --- --- id: KB-LE-032 url: https://app.codecontract.io/help/legal/separating-what-is-yours-from-what-is-shared idioma: en categoria: sector-legal subcategoria: familia audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-010, KB-LE-003, KB-LE-018] citadoPor: [KB-LE-026] --- # Separating what is yours from what is shared _Twenty years of two people's papers in the same folders. Sorting them is half the matter, and nobody counts it as work._ **Responde a:** gathering documentation for a family matter · papers in both names how to separate them · financial records going back years · no access to documents in the other party's name What has to be gathered is not in a company archive: **it is in twenty years of a shared life**, in shared folders, in accounts in both names, in emails from a time when nobody thought this would be needed. And unlike any professional matter, here the other party had access to the same things you did throughout, and some documents exist only on one side. ## Where each thing sits, and who can reach it | Kind of document | Where it usually is | Who can obtain it | | --- | --- | --- | | In your name | Your mail, your bank | You | | In both names | Either side | Both, usually | | In the other's name | Beyond your reach | **Through the procedure** | | **On paper, at home** | **Wherever it was** | **Whoever is there** | > [!IMPORTANT] > **What can be gathered calmly before things become tense bears no resemblance to what can be gathered afterwards.** It is not a strategic recommendation, it is a practical observation: shared access gets closed, papers move house and conversations stop being easy. Sorting and keeping a copy of what is yours and what is shared, somewhere that is yours, only makes sense to do beforehand. ## What helps whoever is handling the matter 1. **Gather it by year and by category** — It is how it will be looked at: what existed on such a date, what was paid each year. 2. **Keep the original, not only a photo** — A photo of a statement is worth less than the statement. 3. **Note what is missing and why** — «It is in the other's name» is useful information, not a gap. 4. **And hold it somewhere of your own** — Not on a device or account shared with the other party. > [!WARNING] > What makes this position particular, and harder than any professional matter, is that **the documentation is also the memory of a life**. Sorting it is not an administrative task: it takes longer than expected, it is done worse than it would be in another context, and it gets postponed for reasons that have nothing to do with efficiency. Allowing for that —giving it time, doing it in stretches, asking for help— is part of doing it properly, not a weakness. > [!NOTE] > What documentation each kind of procedure requires, what can be requested when it is held by the other party and what deadlines apply **is determined by the applicable rules and settled by your lawyer**. Here we cover the organisational part: how to gather and keep what will be needed, and how to hold it somewhere that is yours. **What about things in the other party's name?** Note that they exist and where. How to obtain them is for your lawyer. **Does a photo of a document count?** It helps to know it exists; the original is usually still needed. **Where do I start if it is many years?** With the financial side, by year. It is what is asked for most and the easiest to order. ## Ejemplos **Years of documentation sit in shared folders.** - Gathers your own copy in a space that is yours → What is needed stops depending on shared access. **Financial information has to be provided year by year.** - Organises documents by date and category → It is provided the way it is asked for. **Documents in the other party's name are missing.** - Allows noting what is missing and why → The gap is documented rather than left blank. **The papers exist as loose photos on a phone.** - Stores documents in an ordered file → What is provided stops being a camera roll. **The lawyer asks for something and it is hunted each time.** - Shares the file with whoever handles the matter → The request is met without a fresh search. **Sorting it all at once feels unmanageable.** - Allows adding in parts and seeing what is missing → The work happens in stretches and progress is visible. --- --- id: KB-LE-033 url: https://app.codecontract.io/help/legal/the-firm-changing-tools idioma: en categoria: sector-legal subcategoria: legaltech audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-021, KB-LE-001] citadoPor: [KB-CS-044] --- # The firm changing tools _Twenty years of case files and a new tool. Whatever does not travel in the migration stops existing for the firm._ **Responde a:** migrating case files to another system · changing document manager in a law firm · what happens to the history when changing software · getting my data out of a tool Changing tools looks like an IT project and is an archive project. **What is being moved is not data: it is twenty years of clients' case files**, some closed, some live, and all with retention obligations that do not depend on which program you use. The decision about what migrates and what does not will be taken by somebody looking at a quotation, and its consequences will last a decade. ## What a migration actually decides | The decision | How it is presented | What it really means | | --- | --- | --- | | Migrate only active matters | Cost saving | Closed ones stop being to hand | | Migrate the last few years | A middle way | There is a cut-off, and you must know where | | Migrate everything | More expensive | The history stays whole | | **Leave the old one «just in case»** | **No cost** | **Lost when it is switched off** | > [!IMPORTANT] > **The option of «leaving the old system running just in case» is the one most often chosen and the only one that is not a decision.** Nobody sets how long, nobody maintains it, and a day comes when it is switched off over a licence renewal, a retired server or a supplier that closes. That day the entire history is lost, without anyone having decided it and without anyone noticing until somebody looks for something. ## What to settle before signing for the new tool 1. **Exactly what migrates and what does not** — Decided on retention grounds, not only on cost. 2. **How everything gets out of the new tool** — Ask BEFORE going in. Afterwards it is a negotiation. 3. **What happens to the old system and when** — With a date. «It stays for now» is not a plan. 4. **And that retention obligations are preserved** — Changing program does not change how long things must be kept. > [!WARNING] > The question to ask before contracting any tool, and almost never asked because it sounds like distrust, is **how you get out of it**: in what format documents come out, whether they come with their structure and metadata or as a flat folder of files, and what it costs. Asking before signing is a condition; asking three years later, when you already want to leave, is asking a favour of someone with no incentive to make it easy. > [!NOTE] > What retention, confidentiality and security obligations apply to your clients' files, and what must be guaranteed when changing provider or system, **is determined by professional rules and data-protection law, and settled by your professional body or adviser**. Here we cover the organisational part: how to move an archive between tools without losing years along the way. **Do I migrate everything or only active matters?** It depends on cost, but also decide what happens to what does not migrate. **Can I leave the old system running?** Yes, with a date and an owner. Without those, it will switch itself off one day. **What do I ask before contracting?** How you get out, in what format and at what cost. Before, not after. ## Ejemplos **Only active matters migrate and closed ones stay in the old system.** - Allows keeping the complete history in one place → There are not two archives to maintain at once. **The old system is switched off and nobody had set a date.** - Keeps the archive outside the tool of the day → The switch-off does not take the previous years. **On trying to change, documents only come out as a flat folder.** - Allows exporting with structure and context → The archive stays usable elsewhere. **A matter closed eight years ago has to be consulted.** - Keeps closed files accessible and searchable → The history still supports the work. **Retention obligations get lost in the change.** - Applies the retention policy across the whole archive → The period does not depend on the program. **Nobody knows exactly what migrated and what did not.** - Records what was transferred and when → The cut in the history is documented. --- --- id: KB-CS-009 url: https://app.codecontract.io/help/legal/law-and-accountancy-firms-client-documents idioma: en categoria: sector-legal subcategoria: despachos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-005, KB-CO-012] citadoPor: [KB-CS-022, KB-LE-001] --- # Law and accountancy firms: client paperwork _Requesting it, keeping it findable, and handing it back whole when the time comes._ **Responde a:** request documents from clients law firm · accountancy client document management · hand over the file when a client leaves · engagement letter signing A firm lives on other people's paperwork: it requests it, keeps it, uses it and one day gives it back. All three moments have friction, and the last one leaves the worst impression when it goes badly. ## Requesting it Each type of engagement always needs the same things. Built as a process, the client receives the list and works through it, instead of an email chain where nobody knows what is outstanding. ## Keeping it Organised by client, not by year or by who uploaded it. That is how people ask for it: nobody phones asking for "the 2024 stuff". ## Giving it back When a client leaves — and some do — being able to hand over their whole file with its dates in one download says more about your firm than any brochure. The alternative, two weeks gathering paper, is remembered badly. | Moment | What usually fails | What avoids it | | --- | --- | --- | | New engagement | An email chain with no view of what is missing | A process per engagement type | | During | Documents sitting in a partner's inbox | Having them in the client's case | | Client leaves | Two weeks gathering | One download | > [!IMPORTANT] > Client documentation belongs to the client. Withholding it or delaying its return over an unpaid invoice is delicate ground; check with your professional body before doing it, not after. > [!WARNING] > A firm holds documents for clients who compete with each other. Scoping each case to whoever handles that client is not internal bureaucracy: it is what prevents a serious problem. > [!NOTE] > An engagement letter signed electronically before work starts avoids the sector's commonest scope dispute. **Can I give the client access to their own?** Yes, read-only and only to their case. **Does it serve for anti-money-laundering files?** Identification documents are requested and kept like everything else, with their dates. **What if the client sends everything by WhatsApp?** You can request there too, but the document ends up in the case, not on someone's phone. ## Ejemplos **An accountancy firm loses a twelve-year client who asks for their whole file.** - Downloads the complete file with its dates - Hands it over in two days → The client returns eighteen months later, and says so: it was the way they were let go. **The client sends their papers through four channels.** - Agrees a single delivery channel → Deliveries stop getting lost. **A client asks what they are missing.** - Shows them their own outstanding list → They answer without a phone call. **The documentation lives in the inbox of whoever handles the client.** - Gathers the file in a shared place → The answer does not depend on who is in. **A client document expires.** - Records expiries per client → The warning arrives before it bites. **A client leaves and asks for everything of theirs.** - Checks their complete file → The handover is prepared in hours. --- --- id: KB-CS-011 url: https://app.codecontract.io/help/use-cases-by-sector/rentals-from-contract-to-handover idioma: en categoria: casos-por-sector subcategoria: inmobiliario audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-015, KB-SC-006, KB-LE-017] citadoPor: [KB-CS-034] --- # Rentals: from contract to handing over the keys _Signing without in-person appointments, and proving the property's condition._ **Responde a:** sign a tenancy agreement remotely · property handover inventory · condition of the flat when the tenant moves in · manage rental documentation A tenancy has two moments that get disputed years later: what was signed and what condition the property was handed over in. The first is settled by the signature; the second, which is what ends up in a deposit dispute, by photos certified on the day. ## The four steps 1. **The tenant's documents** — Identity, payslip or proof of income, guarantor if any. Ask for the minimum: this is personal data about someone who is not yet your tenant. 2. **The contract, for signature** — Signed with a phone code. Nobody has to travel and no diaries have to match. 3. **The inventory and photos** — On handover day, with the property empty. Certified that day, not when the problem appears. 4. **The key handover receipt** — Signed too. It is what fixes the real start date. > [!IMPORTANT] > Handover condition photos are what decide a deposit dispute, and they only count if dated by a third party. A photo with the phone's own date proves nothing: anyone can change a phone's clock. ## On the way out, the same in reverse Photos of the condition on return, certified that day, compared with the move-in set. With both series dated, the deposit conversation lasts ten minutes instead of three months. > [!WARNING] > Be careful holding more tenant data than you need. You have no reason to keep payslips from applicants who did not rent, and they are exactly what you do not want to hold if a security problem ever arises. > [!NOTE] > If you manage several properties, the process is identical each time: built as a template, a new tenancy costs ten minutes instead of an afternoon. **Is a tenancy agreement signed this way valid?** Electronic signatures are valid; for specific requirements of your contract type, ask your adviser. **Can the tenant sign from a phone?** Yes, and that is the norm. **What about two tenants?** Both as signers, in parallel: each signs when they can. ## Ejemplos **A letting agent argues over several deposits a year about handover condition.** - Certifies photos on handover day and on return day → Disputes close by comparing two dated series, with no surveyors or lawyers. **A letting agency runs forty seasonal rentals and reclaiming a deposit means three documents in three email threads.** - Gathers contract, inventory and receipt in each booking's project - Captures the property's condition at handover of keys - Shares the whole project when reclaiming the deposit → The claim is prepared in minutes and rests on what was recorded on handover day. **There is a dispute about the condition the property was handed over in.** - Captures dated photos at handover and at return → The dispute closes by comparing rather than arguing. **The signed contract sits in the inbox of a salesperson who has left.** - Stores the signed copy in the booking's project → The contract outlives the person's departure. **The tenant says they never received the inventory.** - Sends from the platform and checks delivery → It is on record when it was delivered and to whom. **The contract is renewed and nobody knows which version was signed.** - Keeps each version with its date → You provide the one that covered that period. **The tenant's documentation contains personal data with no control.** - Limits who sees anything containing it → Access stops being general. **The tenancy ends and everything mixes with the next one's.** - Closes that booking's project → Each season's history is readable. --- --- id: KB-CS-012 url: https://app.codecontract.io/help/use-cases-by-sector/patient-informed-consent idioma: en categoria: casos-por-sector subcategoria: sanitario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-013, KB-TZ-003] citadoPor: [KB-CS-013] --- # Patient informed consent _Signing without paper where the data is especially sensitive._ **Responde a:** digital informed consent · patient signatures in a clinic · healthcare documents data protection · consent before a procedure Informed consent is not signed to have a piece of paper: it is signed to be able to prove that person understood what was going to be done before it was done. That changes what matters: date and identity outweigh convenience. ## What must be provable **En corto** - That the specific person signed, not someone on their behalf. - That they signed BEFORE the procedure, with the time. - Which exact version of the document they read. > [!IMPORTANT] > This handles health data, which carries heightened protection. It is not just another document type: decide expressly who can see it, how long it is kept and whether automatic reading applies, rather than leaving the defaults. ## The order that avoids the problem | Moment | What happens | | --- | --- | | When booking | Consent is sent, with time to read it | | Before the procedure | Signature is checked. No signature, no procedure | | Afterwards | The copy with evidence goes into their record | _Sending it in advance is not courtesy: consent signed hurriedly in the room is exactly the one that gets disputed._ > [!WARNING] > If the patient cannot sign for themselves, whoever signs must be identified as who they are and in what capacity. Signing "for" someone without recording who you are invalidates precisely what was meant to be proved. > [!NOTE] > For minors, whoever holds legal responsibility signs, and it is worth recording who that is. It is the case where verified identity by phone code is most appreciated. **Can it be signed at the clinic?** Yes, from a tablet or their phone. What matters is that identity and time are recorded. **How long must it be kept?** Whatever the applicable healthcare regulations require; check with your adviser. **Can consent be withdrawn?** Withdrawal is recorded as a new document; the earlier consent is not deleted, because it proved what was true then. ## Ejemplos **A clinic has consent forms signed on paper the same day, in the room.** - Sends them when booking, with time to read - Checks the signature before proceeding → Rushed consent disappears, and the date proves there was time to read. **A clinic files consents on paper and takes two days to locate one from a patient three years ago.** - Signs the consent electronically and stores it in the patient's file - Keeps the signature evidence with the document - Limits who can open those files → The consent is located in seconds and its signature can be defended against anyone questioning it. **A patient denies having signed.** - Provides the document with its evidence chain → The moment and the device of signing are on record. **It is signed on paper and nobody notes the time.** - Signs electronically with the date recorded → The time stops being the first thing argued about. **The consent is stored with clinical data accessible to the whole centre.** - Limits access according to each person's role → Sensitive material stays where it should. **The consent wording changes and versions coexist.** - Keeps each version with its date → You know what each patient signed. **The patient asks for their copy years later.** - Checks the file and provides it → The request is met without searching physical archives. **A patient asks for their data to be deleted.** - Locates where it appears and acts on the policy → The request is handled on a basis. --- --- id: KB-CS-013 url: https://app.codecontract.io/help/use-cases-by-sector/permission-slips-from-families idioma: en categoria: casos-por-sector subcategoria: educacion audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-004, KB-CS-012] citadoPor: [KB-CS-040] --- # Permission slips from families _Trips, image rights and enrolments: signing with hundreds of families at once._ **Responde a:** trip permission slip · student image rights consent · enrolment signed by parents · collecting school permissions The pattern is always the same: two hundred families have to sign something before a date, and the ones missing have to be phoned the day before. It is the case where automating the chasing gives back the most time. ## The three types and what changes in each | Document | What matters | Typical window | | --- | --- | --- | | Trip or outing | That all are in before departure | Two weeks | | Image rights consent | That it can be withdrawn later | At enrolment | | Enrolment | Identity of whoever signs | Enrolment period | > [!IMPORTANT] > Image rights consent for a minor is not just another form. It has to be withdrawable at any time, and that withdrawal has to reach whoever publishes the photos — filing it is not enough. If you are unsure how it applies in your case, ask before publishing anything. ## What makes them arrive on time **En corto** - Send two weeks ahead and remind at days 3, 7 and 12. - SMS for families who do not read email, and there are many. - See who is missing as a list, rather than cross-checking by hand. > [!WARNING] > Do not send the permission to the school's general address or to a group: it has to reach whoever holds legal responsibility for the child, and the record has to show who signed. > [!NOTE] > The list of who is missing saves the most time. Going from "phone everyone just in case" to "phone these six" turns an afternoon into twenty minutes. **Can both parents sign?** Yes, by adding both as signers if your situation requires it. **What about families without a phone or email?** There will always be a paper remainder; the aim is to shrink it, not eliminate it. **Can it be reused each year?** Yes, as a template: change the date and the list. ## Ejemplos **A school chases 210 trip permissions and phones dozens of families the night before.** - Sends two weeks ahead with automatic reminders - SMS to families without email → The day before, six are missing instead of forty, and they take twenty minutes. **A school sends excursion consent forms home in schoolbags and by Friday thirty are missing.** - Sends the consent for signature from a phone - Checks who is missing without recounting papers - Chases only those who have not signed → By Friday you know exactly who is missing and you phone thirty families instead of two hundred. **A family says they never received the form.** - Checks the send and open dates → It is on record when it was delivered. **It is signed on paper and lost in a schoolbag.** - Signs from a phone with nothing printed → The consent arrives even if everything else is lost. **Separated parents both sign and nobody checks.** - Records who must sign in each case → The consent is valid for what is needed. **The consent arrives on the day of the trip.** - Sends in advance and chases automatically → The day of the trip is not spent collecting signatures. **Family data is handled with no access control.** - Limits who sees pupil files → Sensitive material stays where it should. **Every year the list and the send are rebuilt.** - Saves the process as a template → Next year costs minutes. --- --- id: KB-CS-014 url: https://app.codecontract.io/help/use-cases-by-sector/contracting-with-individual-clients idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-015, KB-CF-004, KB-CS-032] citadoPor: [KB-CS-033, KB-CS-035] --- # Contracting with individual clients _Quote accepted, contract signed and work started the same day._ **Responde a:** get the client to sign the quote · service contract with an individual · accept a quote remotely · signing with clients without an office An installer, a photographer, a workshop, a refurbishment firm: the pattern is identical. A quote goes out, the client says yes on WhatsApp, and when a problem arises that "yes" turns out to fix nothing — not the scope, not the price, not the timescale. ## What changes when it is signed | With an "OK" by message | With the quote signed | | --- | --- | | No record of which version they accepted | The exact document is on record | | No record of when | A certified time is on record | | Arguing scope is their word against yours | The scope is the one they signed | ## The full circuit, in a day 1. **You send the quote for signature, with scope and timescale inside.** 2. **The client signs from their phone, no account, nothing to install.** 3. **You start work with the scope fixed.** 4. **On completion, the sign-off, also signed.** > [!IMPORTANT] > The sign-off at the end is the most forgotten and the one that prevents the most trouble when invoicing. Work delivered without a signed sign-off is what gets disputed when the invoice arrives. > [!WARNING] > If you work with consumers, there are prior-information and cancellation requirements that depend on your activity. The platform helps you prove what was signed and when; what that document must say comes from regulation, and is worth asking your adviser about. > [!NOTE] > For small jobs it can feel excessive. It does, until the first client who disputes the scope: after that it costs two minutes and saves weeks. **Does it cost the client anything?** No, never. **Do they need to install anything?** No. They open a link and sign. **What if the scope changes midway?** A signed amendment. Faster than arguing about it at the end. ## Ejemplos **A refurbishment firm accepts quotes on WhatsApp and argues about scope on half its jobs.** - Sends the quote for signature, scope included - Asks for a signed sign-off on completion → Scope arguments disappear and invoices get paid without the usual conversation. **An installer signs quotes with private customers in their living room and then loses them.** - Sends it for signature from a phone on the spot - Stores the signed copy in the customer's project - Keeps the evidence with the document → The quote is signed before leaving the customer's home and does not depend on a piece of paper. **The customer denies having accepted the quote.** - Provides the signed copy with its evidence → The acceptance holds up. **It is signed on paper and scanned days later.** - Signs electronically on the spot → The print-and-scan round trip disappears. **The customer asks for a copy months later.** - Checks the project and provides it → The request is met without searching. **The quote is changed verbally during the works.** - Records the change in writing and has it signed → The final invoice surprises nobody. **The private customer's data is kept with no criteria.** - Applies the retention policy → What is kept has a reason and a period. **The customer has neither computer nor email.** - Signs from their own phone with nothing to install → The signature is resolved there and then. --- --- id: KB-CS-023 url: https://app.codecontract.io/help/use-cases-by-sector/vessel-and-crew-documentation idioma: en categoria: casos-por-sector subcategoria: maritimo audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-024, KB-CF-002] citadoPor: [KB-CS-024, KB-IU-015] enLaApp: https://app.codecontract.io/flota/vessels --- # Vessel and crew documentation _Certificates that expire at sea and crews that change every trip._ **Responde a:** vessel document control · expired ship certificates · fishing crew documentation · vessel registry imo certificates A vessel accumulates more documentation than a construction site, with one uncomfortable difference: when something expires, the ship may be three days from port. The check cannot happen on arrival; it has to happen before sailing. ## The three levels, as with machinery but harder | Level | What it covers | Expires | | --- | --- | --- | | The vessel | Registration, IMO, call sign, class and safety certificates | Yes, nearly all of it | | Its equipment | Beacons, life-saving, firefighting, inspections | Yes, on different dates from each other | | The crew | Certificates of competency, medicals, safety training | Yes, and it changes every trip | > [!IMPORTANT] > The cross-check between vessel and crew is what decides whether it sails. A ship with every certificate current and one crew member with an expired medical has a problem, and it is the same problem as a missing ship certificate. ## Why the warning has to be long Renewing a vessel certificate is not asking for a piece of paper: it can mean an inspection, a technical stop or coordinating with a classification society. Sixty days is tight; ninety is reasonable for anything depending on third parties. > [!WARNING] > Crews rotate, and whoever boards on Tuesday may not be who was on Friday's list. Control has to be per person and checkable before boarding, not a company roster. ## Frameworks cited International conventions on maritime safety and on seafarer training and certification, registration and flag rules, and — in fishing — the specific obligations of fishing activity. Which certificates your vessel type and fishing ground require is confirmed by your maritime authority or your adviser. > [!NOTE] > One case per vessel, with its equipment and crew inside, lets the skipper check from a phone before casting off. It is the same pattern as site access control, somewhere getting it wrong costs more. **Can I manage several vessels?** Yes, one case each, identified by IMO. **What about temporary crew?** Same as permanent: a participant with their documents and expiries. **Does it serve for a port inspection?** It is exactly what gets shown, and from a phone. ## Ejemplos **An owner with six vessels finds at an inspection that a crew member sailed with an expired medical.** - One case per vessel, with crew as participants - 90-day warnings on anything depending on third parties → The skipper checks from a phone before sailing, and it stops depending on someone in the office remembering. **A vessel arrives in port and a crew certificate that expired at sea is missing.** - Records expiries per person and per vessel - Warns with the lead time each process needs - Checks the status before the vessel sails → The vessel is not detained over a paper that could have been renewed three weeks earlier. **The vessel's documentation is on paper on board.** - Also keeps it accessible ashore → A soaked paper stops halting a port call. **Part of the crew changes at the last port.** - Checks per person before embarkation → The crew change is not found incomplete at inspection. **An inspection asks about a certificate from two years ago.** - Keeps the history with its date → You answer from the archive. **Each vessel keeps its documentation its own way.** - Uses the same file structure for all → The fleet is reviewed in one go. **A certificate is renewed and nobody updates the file.** - Records the renewal on receipt → The status reflects reality. **Documentation reaches the owner weeks later.** - Captures it at the moment and shares it → The owner sees the status without asking. --- --- id: KB-CS-024 url: https://app.codecontract.io/help/use-cases-by-sector/catch-certificates-and-traces-submissions idioma: en categoria: casos-por-sector subcategoria: maritimo audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-023, KB-NO-004] citadoPor: [KB-CS-023, KB-AL-009] enLaApp: https://app.codecontract.io/cowork --- # Catch certificates and TRACES submissions _Preparing, checking and submitting without redoing the work on every consignment._ **Responde a:** catch certificate traces · submit catch certificates to traces · documentation to import fish · fishery product traceability The catch certificate is the document accompanying fishery products to evidence where they come from and that they were caught legally. Preparing it follows a familiar pattern: a lot of third-party information, deadlines tied to a vessel's arrival, and a submission that has to be right first time. ## What the work consists of 1. **Gather the origin information** — Vessel, area, dates, species and quantities. It comes from the vessel or the supplier, not from you. 2. **Prepare the draft** — This is where missing data shows up, and where you want it to: before submission. 3. **Review before sending** — A person checks the draft. A bad submission costs more than the review. 4. **Submit and keep the receipt** — With its date, which is what proves it went on time. > [!IMPORTANT] > Keeping the submitted draft and its receipt is not bureaucracy: if there is later a discrepancy about what was declared, you hold the exact document with its date. Reconstructing it afterwards from emails is not the same. ## Frameworks cited The European regime against illegal, unreported and unregulated fishing, with its catch certification scheme, and the trade control system used to process it. Exactly what your operation requires — import, re-export, processing — and on what deadlines is confirmed by your adviser or the competent authority. > [!WARNING] > Origin information usually comes from a non-EU supplier, and it is the slowest to arrive. Requesting it when the deal is confirmed rather than when preparing the submission is the difference between arriving early and arriving in a rush. > [!NOTE] > If you always work with the same suppliers and species, most of the work repeats. Built as a process, each consignment costs a fraction of the first. **Can it be reviewed before sending?** Yes, and it should be: the draft is where the gaps show. **What if a supplier's data is missing?** The case shows it was requested and when, which is what lets you chase it. **Is what was submitted kept?** Yes, with its receipt and date. ## Ejemplos **An importer prepares each consignment's certificates from scratch and is always missing a supplier detail.** - Requests origin information when the deal is confirmed, not when preparing the submission - Builds the consignment as a repeatable process → Submissions stop happening at the last minute and the receipt is kept with its date. **A shipment is held at the border because the catch certificate for that specific batch is missing.** - Ties the certificate to the consignment on receipt - Checks what is missing before preparing the shipment - Keeps your own copy as well as the travelling one → The shipment leaves complete and, if something is lost en route, it is reissued without depending on anyone. **The certificate arrives from the supplier without identifying the consignment.** - Requests it with the batch reference → The document can answer for a specific shipment. **A review asks about a shipment from a year ago.** - Keeps the file with its date → You answer without reconstructing. **Consignments from several origins mix in the same shipment.** - Records which consignments make up each dispatch → You can say what came from where. **The certificate expires before the goods leave.** - Records its validity on receipt → The warning arrives before loading. **The supplier changes and the history is missing.** - Keeps your own copy of what was received → The change does not leave you with nothing. **Every shipment is prepared from scratch.** - Reuses what repeats per destination → The second shipment costs half. --- --- id: KB-CS-030 url: https://app.codecontract.io/help/use-cases-by-sector/safety-data-sheets-and-dangerous-goods idioma: en categoria: casos-por-sector subcategoria: quimica audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-NO-002, KB-CS-004] citadoPor: [KB-LG-018] --- # Safety data sheets and dangerous goods _The document that has to be where the product is, not on a server._ **Responde a:** up to date safety data sheet · adr dangerous goods transport paperwork · sending safety data sheets to customers · version control for safety data sheets A safety data sheet has one feature that sets it apart from almost any other document: having it is not enough, it must be in the hands of whoever handles the product, in their language, in the current version. A correct file on your server complies with nothing if the customer is still working from one three years old. ## The three moments where it breaks | Moment | What fails | What prevents it | | --- | --- | --- | | First supply | Sent once, by email, and left there | A recorded send, with proof of delivery | | Version change | Updated without telling previous buyers | A record of who received each version | | Transport | The driver leaves without complete paperwork | Shipment documentation closed before loading | > [!IMPORTANT] > The second row is where real liability comes from. If a product's classification changes and there is no record that you told the customers who already had it, the update does not protect you: it places you. ## How to organise it 1. **One sheet per product and version, not a drawer** — With an effective date, so you know which was current at any past moment. 2. **Sending with proof** — Record who received it, when, and which version. That record is what counts. 3. **Automatic notice on version change** — To everyone who received the previous one, without having to remember. 4. **And transport paperwork alongside the shipment** — Consignment note, instructions and driver training, in the same file. > [!WARNING] > Mind the language. The sheet must be in the language of the country where the product is used: sending the Spanish version to a Portuguese customer is a breach even if the content is identical. ## What an inspection can ask for **En corto** - Which version was current on a specific date. - Who it was sent to and when they received it. - Training records for handling staff, up to date. - And the transport paperwork for one specific shipment. > [!NOTE] > All four are questions about the past, not the present. So what matters is not having today's document filed correctly, but being able to reconstruct which one was right at each moment. **Is a link to the website enough instead of sending the file?** As a supplement yes; as the only delivery, you lose proof of which version they saw. **How often should they be reviewed?** When something relevant about the product or its classification changes, not on a calendar. **What about products we no longer make?** Keep them anyway: someone may hold stock for years. ## Ejemplos **A manufacturer reclassifies a product and updates the sheet on its website.** - Sends the new version to every customer who received the previous one - Keeps delivery proof for each → Facing a claim, it can show who was told and when, not merely that it published the change. **A lorry sits at the bay because the safety data sheet travelling with it is out of date.** - Records each sheet's validity on receipt - Checks the sheet before accepting the load - Carries the sheet accessible from a phone as well as on paper → The lorry leaves with what it should, and a lost paper stops halting a job. **The supplier changes the formulation and the sheet stays the same.** - Asks them to communicate any change → The sheet describes what travels. **A client asks for one specific product's sheet.** - Checks that reference's file → You answer without phoning the supplier. **The sheet is in a language the destination does not accept.** - Asks about the requirement before shipping → The shipment is not held at destination. **A load is accepted without checking its classification.** - Checks the sheet before accepting → The decision is taken with the document in view. **A raw material problem must be contained.** - Checks which production runs used it → Scope narrows to what is affected. **The sheet expires with product in the warehouse.** - Records expiries per reference → The warning arrives before it is used. --- --- id: KB-CS-031 url: https://app.codecontract.io/help/use-cases-by-sector/cold-chain-breaks-what-to-record-and-when-to-report idioma: en categoria: casos-por-sector subcategoria: frio audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-028, KB-LG-007] citadoPor: [KB-LG-014, KB-AL-019] --- # Cold chain breaks: what to record and when to report _Half an hour out of range may be nothing or everything. What decides it is what was recorded._ **Responde a:** cold chain break what to do · temperature records in transport · temperature deviation incident · when to discard chilled product A temperature deviation is not automatically lost product. It can be a badly placed sensor, a door open during unloading, or a real problem. The difference between scrapping a lorry and not scrapping it is almost always the quality of the record, not the deviation. ## What you must be able to show | Element | Why | | --- | --- | | The full curve, not the peak | Half an hour at 9 degrees is not eight hours | | Where the sensor was | A sensor by the door measures something else | | What was done on detection | The reaction weighs as much as the reading | | And who decided what | With a name and a time, not "it was decided" | > [!IMPORTANT] > The third and fourth are forgotten and are exactly what gets asked for. A temperature record with no decision attached proves there was a deviation and does not prove you managed it — which is what gets judged afterwards. ## The protocol in the moment 1. **Log the incident as soon as it is detected** — With the real time. Writing it up at day's end already costs credibility. 2. **Photograph what you can see** — The display, the goods, the seal. With a provable date. 3. **Segregate the affected product** — Identified, until someone decides. Not in the same place as the rest. 4. **And decide against written criteria, not from memory** — With criteria written in advance, the decision takes minutes and is defensible. > [!WARNING] > The costliest mistake is waiting for full information before recording. Record what you know with the time it happened, and expand later. A record created three days after is worth far less even saying exactly the same. ## When to notify outside **En corto** - The customer, if the product already left for them. - The authority, if the product could reach consumption and there is risk. - And the supplier or carrier, always: it is what supports the claim. Windows for the last are short and run from delivery. So the incident should reach whoever claims the same day, not when someone reviews the paperwork. > [!NOTE] > This fits batch traceability: the incident is recorded against the affected batch, not loose. If you later need to narrow what left and where to, it is already linked. **What if the carrier keeps the record?** Request it and keep your own copy: in a claim, their record is their version. **Is a photo of the display enough?** As support yes; the continuous record is what proves duration. **Keep all records or only incidents?** All. Without the normal you cannot show that one was an exception. ## Ejemplos **A warehouse detects a two-hour deviation in a chiller.** - Logs the incident with the real time and photos - Segregates the batch and applies the written criteria → Releases most of the product with a documented decision, instead of scrapping it all as a precaution. **A cold-chain break is spotted at unloading and nobody knows how long it was out of range.** - Records temperature at every handover, not only in transit - Notes the incident at the moment of receipt - Alerts whoever must decide before accepting the goods → The decision to accept or reject is taken with data and in the moment, not three days later. **Goods out of range are accepted and a claim follows.** - Records the incident on receipt → The acceptance is explained and the claim holds up. **The log lives in the lorry's unit and never arrives.** - Collects the log on completing the job → The proof reaches the file. **There is a dispute about which leg broke it.** - Compares the records of both handovers → The dispute closes on data. **Nobody knows how many breaks there were this quarter.** - Checks incidents by period and by route → The pattern shows and the cause gets tackled. **The client is warned late and has already sold the product.** - Warns as soon as it is detected → The client can decide while they still can. **The incident is noted in a notebook in the warehouse.** - Records it in the shipment's file → The record outlives the notebook. --- --- id: KB-CS-032 url: https://app.codecontract.io/help/use-cases-by-sector/garages-and-automotive-services idioma: en categoria: casos-por-sector subcategoria: automocion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-027, KB-IC-012] citadoPor: [KB-CS-014] --- # Garages and automotive services _Approved estimates, warranted parts and customers who do not remember authorising anything._ **Responde a:** signed repair authorisation · garage estimate approved by the customer · parts warranty documentation · customer complaint at a garage The classic garage argument is not technical: it is about what was authorised. The customer remembers a figure, the garage remembers a phone call, and nothing is in writing because the vehicle was on the lift and a decision was needed there and then. ## The three moments worth putting in writing 1. **Reception** — Vehicle condition, mileage, what the customer asks for and what you observe. With photos. 2. **Repair authorisation** — Amount, scope and acceptance. It prevents 90% of arguments. 3. **And the extension, if something turns up** — A second scope accepted, not a phone call each side remembers differently. > [!IMPORTANT] > The third causes the expensive complaints. Another fault appears with the vehicle stripped, the customer is phoned, work continues — and the final invoice doubles the estimate the customer does remember. An acceptance from a phone at that moment costs a minute. ## What the garage gains besides avoiding rows | Element | What it is for later | | --- | --- | | Reception photos | Pre-existing damage later blamed on the garage | | Authorisation with an amount | Non-payment and consumer complaints | | Traceability of the fitted part | Claiming from the supplier if it fails under warranty | | History per vehicle | Seeing what was done last time without digging through paper | > [!WARNING] > The third row recovers the most money and is kept the worst. When a part fails under warranty, claiming from the supplier requires knowing which reference was fitted, when, and to which vehicle. If that only exists on a purchase invoice, the claim is lost for lack of traceability, not for lack of merit. ## What can be automated without complications **En corto** - Next service or inspection reminders per vehicle. - A reminder to the customer sitting on an unaccepted estimate. - And an internal warning when a part warranty is about to expire. > [!NOTE] > It applies equally to commercial vehicle workshops, agricultural machinery, marine and in-house fleets. The machine changes; the authorisation and warranty problem is identical. **Must the customer install anything to accept?** No: they get a link, read it and accept from their phone. **Does a phone acceptance count as evidence?** Yes, and considerably better than a call each side remembers. **What if the customer does not reply?** They are reminded automatically; until they accept, the work is not extended. ## Ejemplos **A garage extends a repair over the phone and the customer disputes the invoice.** - Sends the extension for phone acceptance before continuing - Keeps the reception photos → Invoices stop being disputed and warranty claims to suppliers become defensible. **A garage invoices a repair and the customer disputes authorising half the work.** - Sends the quote for signature before starting - Records each extension with its authorisation - Stores the signed copy in the vehicle's file → The invoice rests on dated authorisations and the dispute closes by looking. **The extension is agreed by phone mid-repair.** - Sends it for signature from a phone on the spot → What was agreed stops depending on two memories. **The vehicle's history sits on paper cards.** - Stores each job in the vehicle's file → The next visit starts knowing what was done. **A customer complains about a repair from two years ago.** - Checks the vehicle's file → You answer from the history. **A part is replaced and there is no record of which.** - Records what was replaced and with what reference → The part's warranty can be claimed. **Photos of the vehicle's condition stay on a phone.** - Captures them into the file on intake → The condition on arrival is demonstrable. **A customer asks for a copy of everything done to their car.** - Checks the complete file → The handover is prepared in minutes. --- --- id: KB-CS-033 url: https://app.codecontract.io/help/use-cases-by-sector/hotels-and-hospitality idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-014, KB-CR-012] citadoPor: [KB-AL-020] --- # Hotels and hospitality _Staff that rotate, suppliers arriving daily, and an inspection that can land any morning._ **Responde a:** hospitality staff documentation · supplier control in a restaurant · hotel inspection paperwork · seasonal onboarding in hospitality Hospitality combines three things that are costly even separately: high staff turnover, many suppliers physically arriving each week, and hygiene and safety obligations that get checked without warning. ## The three fronts | Front | What accumulates | Where it breaks | | --- | --- | --- | | Staff | Contracts, food handling training, uniform issue | Seasonal onboarding signed weeks later | | Suppliers | Health registration, delivery notes, certificates | They arrive on paper with the goods and get lost | | Premises | Fire extinguisher checks, chillers, pest control | They lapse unnoticed until the inspection | > [!IMPORTANT] > The third front draws the most fines and is the easiest to fix: four or five documents with annual expiry. With automatic warnings, it stops being a problem for good. ## What can be solved in a week 1. **One file per site** — With inspections, their dates and who arranges them. 2. **Staff onboarding signed before the first shift** — From a phone, the evening before. It prevents paper that returns in three weeks. 3. **Supplier documentation requested once a year** — With automatic renewal, not delivery note by delivery note. 4. **And the day's photos and records, in the file** — Temperatures, incidents, cleaning. Findable by date. > [!WARNING] > The typical blind spot is the supplier who has arrived every Tuesday for eight years. Nobody remembers when documentation was last requested, and that is exactly who the inspector asks about. ## The morning of the inspection **En corto** - Who was working that day and what training they held. - Where a specific product came from. - The latest premises inspections, with dates. - And the last month's control records. All four are answered from a phone if they live in the site's file. Hunting for them in an office folder with the inspector present is the difference between a formality and a report. > [!NOTE] > It works the same for a chain with twenty sites: one file each, plus a group view of what expires where. The structure is identical; what changes is who reads the summary. **What about casual staff for one event?** Same onboarding, faster: it is where signing runs latest. **Does it suit franchises?** Yes, usually one file per site with head-office access. **What about paper delivery notes?** Photograph them on receipt; what matters is they do not end in a folder nobody opens. ## Ejemplos **A hotel gets inspected and takes two hours to find its premises inspection records.** - Builds the site file with inspections and their due dates - Signs seasonal onboarding the evening before → The next inspection is answered from a phone, with everything dated. **An inspection arrives in the middle of service and the papers are in the office upstairs.** - Keeps the file accessible from a phone - Knows where what is usually asked for lives - Writes down who handles it if the manager is out → It is shown without stopping the kitchen and the visit is resolved in minutes. **A small supplier never sends their technical sheet.** - Asks for little, with an easy place to upload → The sheet arrives without chasing. **Seasonal staff arrive every summer.** - Checks per person what is missing before they start → Onboarding is resolved before the first shift. **Each site keeps its own papers.** - Gathers documentation in one place → The answer does not depend on which site is asked. **A document expires and it is discovered during the visit.** - Records expiries with a warning → The warning arrives before the inspector. **A supplier changes and nobody reviews their documentation.** - Launches onboarding on the first order → No supplier gets in without a file. **A customer asks about allergens and nobody can find the sheet.** - Checks the product's sheet on the spot → The answer arrives at the table, not the next day. --- --- id: KB-CS-034 url: https://app.codecontract.io/help/use-cases-by-sector/property-management-and-communities idioma: en categoria: casos-por-sector subcategoria: inmobiliario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-011, KB-CN-003, KB-CS-036] citadoPor: [KB-LE-017] --- # Property management and communities _Many communities, many suppliers, and owners who want to see things._ **Responde a:** property management documentation · managing agent paperwork · community meeting minutes and resolutions · community suppliers insurance A managing agent runs dozens of communities at once, each with its suppliers, minutes, mandatory inspections and owners asking questions. It is the same work repeated many times, with the particularity that each community is a separate client and cannot see the others' material. ## What accumulates per community | Block | What it includes | Who asks for it | | --- | --- | --- | | Minutes and resolutions | Meetings, votes, approved levies | Owners, and sometimes a court | | Suppliers | Maintenance, cleaning, lifts, insurance | The community itself and insurers | | Mandatory inspections | Lifts, fire systems, water safety, building surveys | Inspectors and insurers | | Incidents | Breakdowns, claims, works | Owners and loss adjusters | > [!IMPORTANT] > The third block creates liability for the agent. A lapsed mandatory inspection in a community you manage is your problem as well as theirs, and warnings with margin are the only realistic way to control it across twenty communities. ## What solves the most 1. **One file per community, genuinely separated** — Each is a client: one cannot see another's. 2. **Due dates per community with an owner** — Lifts, insurance, inspections. That is where the risk sits. 3. **Supplier documentation requested and renewed automatically** — Insurance and certificates, once a year with automatic chasing. 4. **And what owners may consult, accessible** — It cuts calls and emails more than anything else. > [!WARNING] > Watch the minutes: they are the document most requested years later and the worst preserved, because they circulate on paper and by email. Minutes signed and kept in the community's file are found in seconds; hunting for them in a six-year-old archive is not. ## When the agent changes **En corto** - The documentation belongs to the community, not to you. - An orderly handover to the next agent is both an obligation and a calling card. - And being able to export the complete file avoids the argument about what was handed over. That last point is also a commercial argument: arriving at a new community and finding an ordered, exportable archive says a lot about the previous agent, for better or worse. > [!NOTE] > The pattern is identical to a consultancy running compliance for several clients: many identical files, separated, each with its own calendar and a portion visible to the client. **Can owners see everything?** Whatever the community decides; usually their own and common material, not third-party data. **What about levies and payments?** Those live in your management system; documentation and its evidence live here. **Does it suit a single large community?** Yes, though the biggest saving appears with many. ## Ejemplos **An agent manages twenty-two communities and tracks inspections in a spreadsheet.** - Builds a file per community with due dates and owners - Requests supplier documentation annually with automatic renewal → Stops discovering lapsed inspections when the inspector or the claim arrives. **A property manager handles forty communities and an owner asks to see their building's lift contract.** - Organises one file per community - Gives read access to what belongs to each - Records what was shared and with whom → The owner sees theirs without anyone stopping to hunt for it, and without reaching other communities. **A supplier works across several communities and their documentation is requested four times.** - Keeps their file once and links it to each community → The supplier delivers once and it serves all. **An insurance policy expires in one community and nobody notices.** - Records expiries per community → The warning arrives before the meeting. **A meeting is called and documentation is missing.** - Checks what is missing in advance → The meeting happens with everything on the table. **An owner asks you to evidence a cost from two years ago.** - Checks that community's file → You answer without searching cabinets. **The chair changes and the context is lost.** - Keeps the file independent of individuals → The handover does not restart the work. **Information from another community is shared with an owner.** - Checks the scope before sharing → Information does not cross. --- --- id: KB-CS-035 url: https://app.codecontract.io/help/use-cases-by-sector/service-and-maintenance-companies idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-014, KB-CL-008, KB-CS-043] citadoPor: [KB-CL-014, KB-CN-015, KB-CS-041, KB-CS-044] --- # Service and maintenance companies _Technicians out on the road, job sheets, and clients asking what was done last month._ **Responde a:** technician job sheets · maintenance company documentation · evidencing service delivered to the client · maintenance contracts and visits A maintenance company sells something hard to show: visits that happened, checks that were carried out, and breakdowns that never occurred. All its documentation exists to evidence work that, done well, is invisible. ## The three moments to record | Moment | What is recorded | What it is for | | --- | --- | --- | | The visit | Who attended, when, what they did | Justifying the contract and invoicing without argument | | What was found | Condition, readings, photos | Recommending and, if something happens, proving you warned | | What was recommended | With date and the client's response | It is what protects you when the client did nothing | > [!IMPORTANT] > The third saves service companies most often. If you recommended replacing a part and the client chose to wait, that dated recommendation is the difference between their breakdown and your liability. ## How to do it from the road 1. **Job sheet signed on the spot, on a phone** — With the client present. Paper signed and carried in the van gets lost or arrives illegible. 2. **Before and after photos** — Linked to the equipment and the visit, not loose in a gallery. 3. **Recommendations written there and then** — Even one line. A verbal conversation leaves nothing. 4. **And materials used, noted** — It prevents month-end invoice arguments. > [!WARNING] > The costliest mistake is the job sheet filled in that evening or the next day "from memory". Readings are lost, recommendations forgotten, and if there is a claim the sheet's date does not match the visit's. ## What the client asks for **En corto** - How many visits were made and when. - What was done at each. - What is outstanding by their own decision. - And the history per item of equipment, not per date. The last is what they value most and what fewest companies can provide: when a client asks about one machine, they want its full story, not the month's visit list. > [!NOTE] > It applies equally to facilities maintenance, IT services, grounds care, technical cleaning and community services: the pattern is visit, finding and recommendation, with the equipment or site as the thread. **What if the client will not sign the sheet?** Record it anyway, noting the circumstance; better than nothing. **Does it work without signal on site?** Fill it in and sync on leaving; what matters is not leaving it for the office. **Can the client be given access to their history?** Yes, and it drastically cuts "when were you last here?" calls. ## Ejemplos **A maintenance company fills in job sheets at night and argues over invoices monthly.** - Signs the sheet on a phone with the client present - Notes recommendations and materials on the spot → Invoices stop being disputed and a dated recommendation heads off a breakdown claim. **A technician finishes a job at a client's site and the sheet reaches the office four days later.** - Captures the sheet at the job itself - Has the client sign it there and then - Lets it reach the file on completion → The invoice goes out the same day and the client does not dispute what was done. **The client asks what was done last month.** - Checks that installation's history → You answer without phoning the technician. **A technician is stopped at the gate over their documentation.** - Checks per person before assigning the job → The job does not go out with a gap. **Five clients ask for the same documents in five portals.** - Keeps a single current original → All five are answered without redoing the work. **Equipment goes on site and its documentation sits elsewhere.** - Stores it with the equipment → What travels is found where it is. **Photos of the work stay on the technician's phone.** - Uploads them to the file at the moment → The evidence outlives the handset. **A client complains about a job from a year ago.** - Checks the file with its history → You answer from the record. --- --- id: KB-CS-036 url: https://app.codecontract.io/help/use-cases-by-sector/farming-cooperatives idioma: en categoria: casos-por-sector subcategoria: agroganadero audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-025, KB-AL-008] citadoPor: [KB-CS-034] --- # Farming cooperatives _Many members contributing, one brand answering for it, and a season where everything happens at once._ **Responde a:** cooperative member documentation · traceability of member deliveries · farming cooperative season paperwork · member certifications A cooperative has a documentary structure unlike a normal company's: the product is contributed by dozens or hundreds of members, each with their own holding and paperwork, and the one answering to the customer and to an inspector is the cooperative. ## The three layers to sustain | Layer | Whose it is | What is asked for | | --- | --- | --- | | Each member's holding | The member's | Identification, treatments, certifications where applicable | | Intake at the cooperative | The cooperative's | What each member delivered, when, and what was done with it | | The product that leaves | The cooperative's | Which batch contains which deliveries and where it went | > [!IMPORTANT] > The middle layer joins the other two and decides whether the cooperative can answer at all. If intakes are recorded only to settle with the member — weight and quality for payment — it serves the accounts and not traceability: the link between that intake and the outgoing batch it ended up in is missing. ## The season's own problem > [!WARNING] > Everything arrives at once, from people who do not work at the cooperative. Asking a member mid-harvest to supply a certificate is the worst possible combination of timing and recipient. **Member documentation is renewed outside the season**, with months of margin, and during the season you only check that it is there — leave it until the trailer arrives and it will not come. ## What works with members 1. **An annual request, simple and by phone** — Most will never log into any system: they supply from the link and that is it. 2. **With spaced reminders and in their usual language** — And with document names they recognise, not administrative jargon. 3. **Checking before the season opens** — And a clear list of who is current and who is not. 4. **And a written decision for whoever is not** — You receive them anyway, segregate their product, or do not receive them. All three are options; deciding on the spot is not. ## What the cooperative's customers ask for **En corto** - Traceability to the holding, not to the cooperative. - That members' certifications were valid on the delivery date. - And a drill: they pick an outgoing batch and want to reach the plots. That drill is the real test of the system, and it is answered in minutes or in days depending on what was recorded at the weighbridge during the season. > [!NOTE] > What documentation each member must hold and what the cooperative must keep depends on the product, the certification scheme and the region, and it gets updated. **Confirm that with your technical adviser or certifier**; this describes how to organise collection so that nobody has to be chased mid-season. **What about members who do not use a phone?** Collect on paper and have whoever attends at the cooperative upload it: what matters is that it links to the member. **Must documentation of departing members be kept?** Yes, for the period applicable to what they delivered while they were members. **Can field technicians be given access?** Yes, scoped; they are usually the fastest at spotting what is missing. ## Ejemplos **A cooperative asks members for certificates once harvesting has already started.** - Moves the documentation campaign to the preceding months - Checks before opening and decides in writing what to do with those not current → The season is for receiving product, and the customer's traceability drill is answered in minutes. **A cooperative with three hundred members starts the season not knowing whose field records are current.** - Checks everyone's status before the first delivery - Requests and chases automatically those who are missing - Blocks intake only for those who genuinely cannot deliver → The season starts with most members current and the exceptions are handled by name. **A member delivers and their documentation expired in March.** - Records expiries per member → The warning arrives before collection. **A client asks you to evidence a consignment's origin.** - Checks which members made up that batch → You answer per consignment. **Field records arrive on paper in five formats.** - Requests specific documents to a single destination → What is received is comparable. **Chasing three hundred members occupies two people.** - Lets the reminder go out on its own → The two people review instead of nagging. **A small member does not use email.** - Sends them the link on the channel they do use → They deliver anyway and it is recorded. **Deliveries from certified and uncertified members get mixed.** - Records what went into each batch → You can say what came from where. --- --- id: KB-CS-037 url: https://app.codecontract.io/help/use-cases-by-sector/self-consumption-and-small-installations idioma: en categoria: casos-por-sector subcategoria: renovables audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-029, KB-CN-012] citadoPor: [KB-CS-040] --- # Self-consumption and small installations _The installation goes up in days and the documentation stays with the building for twenty years._ **Responde a:** self-consumption installation documentation · solar panel legalisation paperwork · photovoltaic installation certificate · what to keep from a solar installation A self-consumption installation is a short project with long consequences: it goes up in a few days, and the documentation it generates is needed every time the building is sold, a warranty is claimed, maintenance is contracted or the supply account holder changes. ## What remains once the installer leaves | Document | What it is for later | Who holds it if you do not ask | | --- | --- | --- | | Installation certificate | Evidences it was done and with what specification | The installer, and only them | | Registration paperwork | Justifies the installation to whoever asks | Split between installer and agent | | Equipment datasheets and warranties | Claiming when something fails under warranty | The installer, or the manufacturer | | Photos of the installation work | Seeing what lies behind what is no longer visible | Nobody, unless someone took them | > [!IMPORTANT] > The fourth row looks dispensable and is the most appreciated five years on. Once installed, much of the system stops being accessible: conduits, fixings, whatever sits behind a panel. **Half a dozen photos taken during the work are worth more than twice as many pages of technical specification** when something must be repaired or extended. ## What to require before paying the final invoice 1. **The certificate and registration paperwork, complete** — It is the only lever: once paid, the installer's priorities move on. 2. **Warranties with their start date** — Usually commissioning, not equipment purchase. 3. **The as-installed layout and the photos** — Ask explicitly: hardly any installer hands them over unprompted. 4. **And who maintains it and how often** — Even if you decide not to contract it: knowing what should be checked is already useful. > [!WARNING] > The detail that surfaces on sale or letting: **the installation is part of the building and its documentation transfers with it**. A buyer or their bank may ask for it, and not having it can complicate or delay the transaction for a reason nobody associates with panels fitted six years ago. It is the building-manual argument applied to something installed afterwards. ## During the installation's life **En corto** - Every inspection or intervention, into the same file. - Incidents with dates, which is what supports a warranty claim. - And any change of supply account holder. > [!NOTE] > Which procedures, certificates and notifications each installation requires depend on capacity, type and region, and they get updated. **Your installer or engineer confirms that**; this describes which documentation is worth gathering and keeping whatever procedure applies to you. **What if the previous owner installed it?** Ask for whatever exists at purchase: reconstructing it later is expensive and sometimes impossible. **Does the invoice count as evidence?** As expenditure yes; as evidence of the installation, no. **Is this needed for a small installation?** The volume of paper is smaller, but the problem at sale is identical. ## Ejemplos **A company sells a warehouse and the buyer asks for the solar documentation.** - On the next installation, requires certificate, registration and photos before the final payment → The documentation travels with the building and the deal is not held up by a years-old paper. **A solar installer delivers thirty systems a year and each legalisation file is built from scratch.** - Saves the complete process as a template - Requests what depends on the customer on day one - Checks what is missing per installation before filing → The thirty-first installation is processed in a fraction of the time the first took. **A customer document is missing and the filing stalls.** - Requests what depends on them when the contract is signed → The wait runs in parallel with the works. **The customer asks for the documentation years later for a grant.** - Keeps the complete file with its date → The request is met without reconstructing. **A component is replaced and the documentation stays the same.** - Updates the file with every change → The paper describes what is installed. **Installation photos stay on a phone.** - Uploads them to the file at the moment → The evidence outlives the handset. **Later maintenance does not know what was installed.** - Stores the file with the installation → Whoever maintains it finds what went in. **Each technician documents differently.** - Uses the same template for everyone → The files are comparable. --- --- id: KB-CS-038 url: https://app.codecontract.io/help/use-cases-by-sector/a-food-shop-that-also-makes-its-own idioma: en categoria: casos-por-sector subcategoria: alimentacion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AL-013, KB-AL-007] citadoPor: [KB-CS-043] --- # A food shop that also makes its own _Selling what you buy and selling what you make are not the same activity, even under one roof._ **Responde a:** shop that sells and prepares food documentation · I make takeaway dishes in my shop · what paperwork if I prepare and sell · kitchen inside a shop A butcher making burgers, a greengrocer pressing juices, a corner shop with takeaway dishes, a bakery that also resells. It is the most widespread model and the one that causes most confusion, because two activities that look nothing alike on paper share the same premises. ## What changes depending on what you do with the product | What you do | What you answer for | What documentation it carries | | --- | --- | --- | | Selling what you buy, as is | Storing and selling it properly | Your suppliers' papers, plus goods-in checks | | Cutting, packing or mixing | What comes out of your hands | Plus what you do and with what | | Making a new product | The whole product | Ingredients, process, allergens and what you declare | | Serving for eating in | What is served at that moment | And informing whoever asks what it contains | > [!IMPORTANT] > The step from the first row to the rest is crossed without noticing: **the day you open a pack and do something with what is inside, you stop being the reseller and become the maker**. That tray of marinated meat or that fresh juice no longer carries your supplier's label: it carries yours, and you answer for what it says. It is not a new formality, it is a change of role that happens within a single working day. ## The minimum you must be able to show 1. **For what you buy: who sold it and when it arrived** — Delivery note and batch. That is what lets you look backwards if there is a problem. 2. **For what you make: what each item contains** — With allergens identified, which is the first thing you will be asked. 3. **What you do to keep it right** — Cleaning, temperatures, goods-in checks: your own records. 4. **And the training of whoever handles food** — Always requested, and almost always out of date. > [!WARNING] > What causes most trouble in a shop is not the preparation: it is **the label on what you pack for sale**. When you prepare trays and put them on the counter with a price, that pack has to say what is in it. It is where a small shop doing things properly picks up a warning — not for how it prepares food, but for what is missing from the label it printed itself. ## If you also sell to other businesses **En corto** - Selling to a restaurant or another shop is not the same as selling to the public. - There you become a supplier, and will be asked for what you ask of yours. - And that client may require product specifications you never needed before. > [!NOTE] > Which records are compulsory, what must appear on each label and what is required to prepare food on the same premises where it is sold depend on food regulations and on your region. **Your adviser or the relevant health officer confirms that**; here we explain where the line between reselling and making sits, because it orders everything else. **Does preparing only a little count the same?** Quantity does not change the role: if it comes from your hands, it is yours. **Is the supplier's spec enough for what I prepare?** For the ingredient yes; for your product no: you define that one. **What if I only cut it up?** Cutting is already handling, and it carries its own records. ## Ejemplos **A butcher starts selling prepared trays under its own label.** - Defines what each preparation contains, allergens included, before it hits the counter → The label they print says what it has to say, and the warning does not come from there. **A shop that also prepares food gets an inspection and cannot tell what it buys from what it makes.** - Separates the supplier file from the preparation file - Records what goes into each preparation - Keeps both accessible from the counter → You answer for what is sold, bought or prepared, without leaving the shop. **Preparation uses a raw material whose sheet has expired.** - Records expiries per reference → The warning arrives before preparing with it. **A customer asks about allergens in a prepared product.** - Derives it from the recorded ingredients → The answer arrives at the counter. **An ingredient changes and the label stays the same.** - Reviews which preparations contain it → The label keeps telling the truth. **An ingredient problem must be contained.** - Checks which preparations used it → Scope narrows to what is affected. **Small suppliers do not send their sheets.** - Asks for little, with an easy place to upload → The sheet arrives without chasing. **The documentation sits in a folder in the back room.** - Captures it and stores it in the file → It is shown from the counter. --- --- id: KB-CS-039 url: https://app.codecontract.io/help/use-cases-by-sector/an-installer-working-for-several-main-contractors idioma: en categoria: casos-por-sector subcategoria: construccion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-001, KB-CS-006] citadoPor: [KB-CS-041] --- # An installer working for several main contractors _The same documents, requested by five different clients, on five different portals, in five different formats._ **Responde a:** uploading documents to several contractor portals · asked for the same thing on every site · subcontractor documents for site access · refused site access over paperwork If you are the company going on site, you live this every week: each main contractor has its portal, its checklist and its criteria, and they ask for the same thing under a different name. The temptation is to treat each client as a separate world. That is exactly what leaves an operative at the gate one morning. ## What is shared and what belongs to each client | Document | Does it change by client? | Where it should live | | --- | --- | --- | | Company ones: insurance, social security, prevention | No, it is the same paper | In one place, copied out to each portal | | Each worker's | No, but requested per site | Per person, with their expiry dates | | Equipment ones | No, requested per machine | Per machine, with its serial number | | The contractor's own forms | Yes, and there is no shortcut there | With that site's file | > [!IMPORTANT] > The expensive mistake is keeping documentation **by client instead of by item**. When the insurance renews, whoever files by client has to remember to update it in five places, and one always gets missed — usually the site you are entering next week. Filed by item, the insurance is one document, and what changes is which portals it goes to. The first is impossible to maintain; the second is half an hour a month. ## How the real work is organised 1. **A company file, with expiry warnings** — It is the folder copied wholesale into each new portal. 2. **A file per worker and one per machine** — With training, medicals and inspections, each with its date. 3. **And a list per site of what that contractor asked for** — Because their next site will ask for the same. 4. **With the date each item was uploaded to each portal** — That is what settles the «we never received it» argument. > [!WARNING] > What costs the most working days and nobody plans for: **each portal's validation takes time**. Even with everything uploaded correctly, someone on the other side has to approve it, and that can take days — not minutes. If the operative starts on Monday, the documents do not go up on Friday. And if one is rejected over a formatting detail, the clock restarts. That margin is the difference between getting on site and losing a crew's day. ## When the criteria change halfway **En corto** - Ask in writing exactly what is missing: «incomplete documentation» is not an answer. - Keep what was rejected and why: it repeats on the next site. - And if one client demands something nobody else asks for, treat it as theirs, not as a general rule. > [!NOTE] > What documentation is required for site access, and what obligations each company has on prevention and coordination of activities, depend on the applicable rules and the type of works. **Your prevention service or adviser settles that**; the point here is not having five copies of the same paper ageing at different speeds. **Can I upload the same file to every portal?** Nearly always yes; what differs are their own forms. **What if a client asks for a document that does not exist?** Ask what they want to prove: something you already hold usually works. **Is it worth keeping what I uploaded?** Yes: half the arguments are about whether it was sent. ## Ejemplos **An installer renews its insurance and one contractor blocks access over the old policy.** - Keeps the insurance once, by item, and lists which portals need it → The renewal propagates in an afternoon instead of surfacing at the site gate. **An installer works for five contractors and uploads the same six documents to five different portals.** - Keeps a single current file of your own - Uploads to each portal from there - Records what was uploaded to each and when → Renewal happens once and gets replicated: five portals stop meaning five jobs. **An insurance policy is renewed and updated in only three portals.** - Checks which contractors it must be replicated to → None is left holding the old version. **A technician is stopped at a site gate.** - Checks per person before assigning them → The job does not go out with a gap. **Each contractor asks for the same document under another name.** - Keeps the original and adapts on upload → The underlying work happens once. **A portal rejects the document without saying why.** - Asks the specific reason before re-uploading → The second attempt is aimed. **Nobody knows what expires in which portal.** - Records expiries in your own file → One warning covers every portal. **Equipment goes on site and its documentation is missing.** - Stores it with the equipment → The machine does not sit at the bay. --- --- id: KB-CS-040 url: https://app.codecontract.io/help/use-cases-by-sector/who-is-allowed-to-work-with-minors idioma: en categoria: casos-por-sector subcategoria: educacion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-013, KB-CF-017, KB-CS-037] citadoPor: [KB-CS-042] --- # Who is allowed to work with minors _The paperwork is not the hard part: the hard part is having it before the person starts on Monday._ **Responde a:** certificate to work with minors · documentation for after-school monitors · what paperwork to ask a coach for · checks on staff working with children A school, a sports club, an academy, the company running the summer camps. The same figure recurs in all four: people coming in to work with children —monitors, coaches, an afternoon's cover, someone delivering a workshop— who need to produce a document before they start. Asking for it is easy. Having it in time is not. ## The four groups that always slip through | Who | Why they slip through | What tends to happen | | --- | --- | --- | | Permanent staff | It was requested on joining, years ago | Nobody rechecks whether it still stands | | The one-week cover | Arrives in a rush and leaves before there is time | By far the most frequent case | | Volunteers and helping families | They are unpaid, so not treated as staff | They are with the children just the same | | The company providing the service | It is assumed they already handle it | The question comes to you | > [!IMPORTANT] > From which comes the one rule with no exceptions: **the document is requested before the person starts, not the day someone asks**. Once the question arrives —a family, an inspection, an insurer— there is no margin left: either it is on record that you checked and when, or it is not. And having seen it once is not enough: a certificate describes a situation on a date, so a paper from four years ago says what was true four years ago. ## How to set it up so it does not depend on anyone remembering 1. **A list of who works with minors** — Updated when someone joins, not every September. 2. **The request goes out with the onboarding** — If it depends on someone writing it, it is forgotten in the first busy week. 3. **With a validity date and an alert before it** — A document with no review date is a document that expires silently. 4. **And whoever lacks it is not on the rota** — That is the only part that makes the rest actually happen. > [!WARNING] > The costliest trap is the contractor one: **the club that subcontracts after-school activities and assumes the company already handles it**. They may well handle it, but you are the ones with the children in front of you and the question will come to you. What to ask for is not a blanket statement that «all our staff are in order», but the list of the actual people coming and their documentation one by one — and to ask again when they swap someone mid-term, which is exactly where it breaks. ## What to keep, and what not to **En corto** - Keep the record that it was requested and was in order, with a date. - Do not hoard extra personal data: the less you hold, the less you have to protect. - Restrict who can open that folder: it is among the most sensitive material you will hold. - And note who checked each one, because «it was checked» with no name supports nothing. > [!NOTE] > Exactly which document must be required, who it covers and how often it is renewed is set by the applicable rules and by the type of activity, and it differs between a school, a club and a camp. **Your adviser or your management settles that**; here we explain why it is worth holding it before anyone starts and how to stop it going stale. **Is the person saying they have it enough?** No: what you will be asked is whether you checked, and that needs a record. **What about a volunteer for a single day?** It depends on the activity; settle the doubt beforehand, never at the door. **How often is it renewed?** No single rule fits everyone: set yours and have the alert fire by itself. ## Ejemplos **A club hires monitors for the year and remembers to ask for their certificate in October, a month after they started.** - Requests the document as each monitor is onboarded, with validity and an alert → Nobody joins the rota without the paperwork in order, and the check is on record with a date and a name. **An after-school activity starts on Monday and on the previous Friday four staff certificates are missing.** - Checks per person what is missing weeks in advance - Requests what depends on the worker at hiring - Blocks assignment for anyone without it → Only those who can start do, and it is not discovered on Friday afternoon. **A monitor joins mid-year.** - Launches the check at onboarding → Nobody starts without what is needed. **The certificate expires mid-year.** - Records expiries per person → Renewal happens before it bites. **A parent asks whether the staff are accredited.** - Checks the team's status → The answer is specific and immediate. **An external company is hired for the activity.** - Passes the same requirement to the subcontractor → The requirement reaches whoever is with the children. **The certificate is stored in a folder with general access.** - Limits who sees anything containing personal data → Sensitive material stays where it should. **An inspection asks about a specific date.** - Checks who was accredited that day → You answer using that day's date. --- --- id: KB-CS-041 url: https://app.codecontract.io/help/use-cases-by-sector/working-inside-someone-elses-site idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-035, KB-CS-039, KB-CS-044] citadoPor: [KB-CS-042, KB-CS-043, KB-CN-026] --- # The company working inside someone else's site _Your work happens somewhere that is not yours, with people inside and under someone else's rules. The paperwork arrives before the technician does._ **Responde a:** documents required to work on a client site · what paperwork do i need for site access · supplier portal keeps rejecting my documents · my technician was turned away at the door You clean a hospital, maintain a factory's machines, run a school canteen or service a shopping centre's lifts. **The work is yours; the site, the rules and the door are not.** That asymmetry turns something that looks administrative —what paperwork you hold— into the condition for invoicing on Monday. ## What they ask for before letting anyone in | Who asks | What for | What happens if it is missing | | --- | --- | --- | | The site | Company documentation | No supplier record is opened | | The site | Documentation for each person entering | The company is approved and the technician is not | | The site | Documentation for the equipment brought in | The machine stays on the loading bay | | **Their client or auditor** | **The same, months later** | **They come back to you for it** | > [!IMPORTANT] > **The distinction almost nobody draws early, and the one that decides whether this holds: there is COMPANY, PERSON and EQUIPMENT documentation, and only the first is stable.** Company papers renew once a year and serve every site. Person papers expire on their own schedule, change whenever someone new joins, and must be ready *before* that person is put on the job. Equipment papers travel with the machine, and the machine moves between sites without telling anyone. ## Why it fails, when it fails 1. **Monday's technician was decided on Friday** — The rota outranks the archive, and the archive finds out afterwards. 2. **Every site wants the same thing under another name, in another portal** — Five clients, five formats, five different renewal dates. 3. **Expiry is silent** — Nobody notices anything until someone is stopped at the door. 4. **Whoever holds the document is not whoever uploads it** — The technician has it on their phone; the person managing the portal is at the office. > [!WARNING] > The costliest failure in this position is not a missing document: **it is that the service goes ahead anyway and the paperwork follows later**. The technician gets in because the guard knows them, does the job, and weeks later a review asks what cover they entered under that day. By then it cannot be fixed backwards. A document uploaded after the day it claims to cover does not cover that day — it only proves you knew. > [!NOTE] > What documentation may be required for site access, what coordination duties exist between the occupying company and those working there, and what training or health surveillance applies to each role **is settled by your prevention service or adviser**, and varies by sector and country. Here we cover the part that decides whether you can answer in time: who holds what, dated when, and who finds out before it expires. **Can I send the same documents to every client?** Company ones, usually. Person ones depend on who you assign to each site. **What if the site insists on its own portal?** It will keep insisting. What you can avoid is holding the original in five places and none of them current. **How far in advance is needed?** Before the person is on the rota, not before they reach the door. ## Ejemplos **A technician is stopped at the door because their training lapsed last month.** - Warns about expiry ahead of time, per person rather than per company → Renewal happens before it hits the rota. **Five clients ask for the same documents through five different portals.** - Keeps a single current original and serves every client from it → All five are answered without redoing the work five times. **Someone new joins the service and nobody knows whether their papers are complete.** - Checks per person what is missing before assigning them to a site → Onboarding stops being discovered at the client's door. **The site asks months later what cover applied on a specific day.** - Keeps each document with its date and who it covered → The answer comes out of the archive instead of being reconstructed. **A machine is brought on site and its documentation sits somewhere else.** - Stores equipment documentation with the equipment, not with the contract → What travels with the machine is found where the machine is. **The technician has the document on their phone and the portal manager cannot see it.** - Collects the document from where the person is, without going through the office → The day's lag between holding it and being able to show it disappears. --- --- id: KB-CS-042 url: https://app.codecontract.io/help/use-cases-by-sector/the-site-that-lets-outside-companies-in idioma: en categoria: casos-por-sector subcategoria: sanitario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-041, KB-CS-040] citadoPor: [KB-CS-043, KB-CN-027, KB-CN-033] --- # The site that lets outside companies in _Eight outside companies work inside your premises every week. If anyone asks who was there on Tuesday, the answer has to exist before the question does._ **Responde a:** what documents to require from a contractor · controlling contractor access to a site · how to know if a supplier is up to date · auditor asking about outside companies A hospital, a care home, a school, a plant or a shopping centre share something a building site does not: **they are running**. Inside there are patients, pupils, residents, customers or a live production line, and on top of that outside companies come in to clean, repair, serve meals or inspect installations. You open the door, and that puts you in a specific position: **you do not do the work and you answer for having allowed it**. ## The three questions that arrive, and where each answer comes from | Question | Who asks | What answers it | | --- | --- | --- | | Is this supplier current? | Your own team, daily | The supplier record — if someone looks at it | | Who came in on Tuesday? | A review, weeks later | The access log matched against who was authorised | | Under what cover did they enter? | A review or an insurer | The document valid **that day**, not today's | | **And the supplier's subcontractor?** | **Almost always, late** | **Knowing they existed before they came in** | > [!IMPORTANT] > **Asking for documentation once, at supplier onboarding, is exactly the same as not asking.** What makes this position useful is not holding a folder of what they sent in January: it is knowing, today, which of those eight companies has let something lapse. Supplier documentation is not an onboarding requirement, it is a state that changes on its own — and it changes for the worse, always quietly. ## What is worth settling 1. **What is required from each kind of supplier** — Night cleaning and touching a critical installation are not the same ask. 2. **Who authorises, and with what in front of them** — If reception authorises and someone else keeps the folder, the door wins every time. 3. **What happens when the supplier sends someone new** — It is the norm, not the exception, and it is where things slip through. 4. **And if the supplier subcontracts** — Decide before it happens, because afterwards it already has. > [!WARNING] > The blind spot of this position: **the supplier complies and their subcontractor does not exist as far as you are concerned**. You contracted one company, vetted it, and on the day a van turns up with a different name on it. If nobody decided in advance whether that is allowed and on what paperwork, the decision falls to whoever is on reception at seven in the morning with the job waiting. It never ends well: either they come in unvetted or a needed service is stopped. > [!NOTE] > What documentation you may require, what coordination and information duties fall on the occupying company, and what applies to personal data of other firms' workers handed to you **depends on the sector and is settled by your adviser or prevention service**. Here we cover the organisational part: how to keep it current and how to answer about a past date. **May I store another company's workers' documents?** With a purpose and a retention period. Your data-protection adviser settles that. **How often should it be reviewed?** It should not be reviewed: you should be told when it expires. That is different and far cheaper. **What if the supplier is slow to send it?** Having the request and its reminder go out on their own avoids the conversation entirely. ## Ejemplos **Eight companies work inside and nobody knows which has let something lapse.** - Shows each supplier's status and warns about what is due → Follow-up stops depending on someone opening the folder. **A review asks who came in on a specific Tuesday and under what cover.** - Keeps each document with its period of validity → The answer uses that day's date rather than today's. **The supplier sends a new technician on the day of the job.** - Checks per person before authorising entry → A new starter is resolved before the door, not at it. **A van turns up carrying the name of a subcontractor nobody expected.** - Records which companies may enter under each contract → Reception decides from a list instead of a phone call. **Chasing every supplier by email costs a morning a week.** - Requests the documentation and chases on its own until it arrives → The morning is recovered and the answer still comes. **Each department keeps its own suppliers' papers in its own folder.** - Brings supplier files together in one place → The question is answered once rather than department by department. --- --- id: KB-CS-043 url: https://app.codecontract.io/help/use-cases-by-sector/the-one-who-won-the-contract-and-subcontracts-it-all idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-041, KB-CS-042, KB-CS-038] citadoPor: [KB-CS-035] --- # The one who won the contract and subcontracts it all _You signed and someone else does the work. As far as the site is concerned there is still one name on the contract, and it is yours._ **Responde a:** liability when i subcontract the service · my subcontractors documentation for the client · client asking for papers of a company that is not mine · how do i control what my suppliers do You win the maintenance contract for twelve sites and you do not have twelve teams: you have arrangements with local firms who deliver it. **The client did not contract those firms, they contracted you**, so anything they ask, they ask in your name. This position carries a very specific trap: the paperwork you will be required to produce is not yours, and you answer for it anyway. ## What you answer for, depending on who is looking | Who is looking | What they see | Who they ask | | --- | --- | --- | | The site | One supplier: you | You | | The subcontractor | One client: you | You | | A review at the site | The whole chain | You, then downwards | | **Your insurer** | **Who actually did the work** | **Whoever can prove it** | > [!IMPORTANT] > **You are the position with the worst information about what actually happens, and the one that has to answer about it fastest.** Whoever is on site sees it; the site lives with it; you find out from a report that arrives on the 5th of the following month, if it arrives. Closing that gap is not about control: it is the only thing that lets you answer without phoning someone who may not pick up. ## What to set up before the first job 1. **What each subcontractor must provide, written and up front** — And no less than the site requires of you, or you pay the difference. 2. **How their paperwork arrives without chasing** — It is third-party documentation, so it has to be requested and chased. 3. **What evidence each job leaves behind** — The report, who did it and when. If nothing remains, for answering purposes it did not happen. 4. **What happens if a subcontractor subcontracts** — If you do not decide it, they will. > [!WARNING] > The classic mistake here is **requiring less of the subcontractor than the client requires of you**, usually because requiring everything would make them dearer or slower. That gap does not disappear: it sits on your balance sheet as a hole that opens on its own the day someone asks. And it is usually discovered at the worst possible moment — after something has happened and the papers of whoever was there have to be produced. > [!NOTE] > What liability the party who subcontracts assumes towards the client and the authorities, and what verification duties they carry over their suppliers, **depends on the contract and the sector, and is settled by your adviser**. Here we cover the part fully within your control: what you require, how it reaches you, and what is recorded about each job. **Can I require of my subcontractor exactly what is required of me?** It is advisable. The gap between what is asked of you and what you ask is your risk. **Must I show my supplier's papers to the client?** It depends on the contract, but being able to is worth it before they ask. **What if the subcontractor sends nothing?** That is the normal scenario. Which is why the request has to chase on its own. ## Ejemplos **The client asks for the documentation of the firm that did the work, which is not yours.** - Keeps each subcontractor's file alongside the contract it serves → It is handed over without phoning anyone or waiting for a reply. **Each subcontractor sends their papers whenever they remember, in whatever format.** - Requests specific documents and chases until they arrive → What arrives is comparable across all twelve firms. **The subcontractor is asked for less than the client asks of you.** - Writes down what is required and checks it is complete → The gap is visible before anyone asks about it. **A site's job report arrives the following month, or not at all.** - Captures the evidence of the work when and where it happens → The month closes on what happened rather than what is remembered. **A subcontractor subcontracts in turn and you find out afterwards.** - Records which firms are authorised under each contract → The chain stops growing without anyone knowing. **Twelve sites, twelve firms and no overall view of who is current.** - Shows the status of every supplier at once → You act on the two that are failing instead of all twelve. --- --- id: KB-CS-044 url: https://app.codecontract.io/help/use-cases-by-sector/discovering-your-data-will-not-come-out idioma: en categoria: casos-por-sector subcategoria: servicios audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-LE-033, KB-CS-035] citadoPor: [KB-CS-041] --- # Discovering your data will not come out _You want to change provider and it turns out the information is yours but out of your reach. You check that on the way in, not on the way out._ **Responde a:** how to get my data out of a provider · data portability from a tool · the provider will not give me my information · changing software without losing the history You have worked with a tool for years and want to change: on price, on service, or because it no longer does what you need. **Then you discover the information is yours in the contract and not in practice**: it comes out in a format that is no use, without context, at an unexpected price, or —at worst— there is no provided way of getting it out at all. ## The four degrees of being stuck | Situation | How you find out | What can be done | | --- | --- | --- | | Everything comes out cleanly | On asking | Change whenever you like | | It comes out unstructured | On opening it | Usable, but costly to rebuild | | It comes out at high cost | On asking for a quote | Decided with a calculator | | **There is no provided way** | **On asking** | **Little, and that is the problem** | > [!IMPORTANT] > **The moment to check how you get out of a tool is before going in, and it is the one question in the buying process nobody asks.** Features, price and support get compared; the exit does not. And yet it determines whether in three years you will have a decision or a situation: changing provider when the data comes out cleanly is a project; when it does not, you simply do not change, however good the reasons. ## What to ask and put in writing 1. **In what format data and documents come out** — And ask for a real sample, not a sales answer. 2. **Whether they come with their context or loose** — A thousand documents with no idea which client they belong to are worth little. 3. **What it costs and how long it takes** — A long lead time can block you as effectively as a high price. 4. **And what happens if the provider closes** — It is the case nobody asks about and the one that ends worst. > [!WARNING] > There is a situation worse than a provider making it difficult, and that is **a provider disappearing**. There is no negotiation, nobody to claim from, and somebody else sets the timescale. The only real protection is not having all the information in one place you depend on: a periodic copy of what matters, in a format openable without them, turns a catastrophe into an inconvenience. It costs little and is appreciated exactly once. > [!NOTE] > What rights you hold over information a provider processes on your behalf, what return and deletion obligations arise at the end of the contract and what must be agreed **is determined by the applicable rules and the contract, and settled by your adviser**. Here we cover the practical part: what to check before going in and how not to end up stuck by default. **When do I check how to get out?** Before going in. Afterwards it is a negotiation from a weak position. **Is it enough that the contract says the data is mine?** Owning it and being able to obtain it are different things. **What if the provider closes?** Which is why a periodic copy of what matters, held elsewhere, pays for itself. ## Ejemplos **You want to change provider and the data does not come out usable.** - Allows exporting documentation with its context → The change is a decision rather than an impossibility. **Documents come out loose with no idea which client they belong to.** - Keeps the link between document and file → What is exported stays usable. **A provider closes and the information must be recovered fast.** - Keeps a copy of what matters outside the provider → A third party failing does not take the archive. **Nobody asked how to get out when contracting.** - Has the exit process agreed and documented → The condition exists from day one. **Information is split across several tools.** - Gathers documentation in one place → You know what exists and where it is. **Extracting the history carries an unexpected cost.** - Keeps the essentials continuously and accessibly → The cost of leaving stops being a barrier. --- --- id: KB-CS-003 url: https://app.codecontract.io/help/use-cases-by-sector/industry-and-manufacturing idioma: en categoria: casos-por-sector subcategoria: industrial audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-002, KB-CR-005, KB-CR-001] citadoPor: [KB-CS-010, KB-CS-004] enLaApp: https://app.codecontract.io/trackline/schemas --- # Industry: shop-floor and supplier control with evidence _Line checks with photo and time, risk-based supplier approval and closed non-conformities._ **Responde a:** paperless shop-floor quality control · industrial supplier documentation · production batch traceability · factory non-conformity management · IATF ISO audit documentation In a factory everything is checked and almost nothing can be proven. Reports are on paper, photos are on different phones, and supplier approval lives in a spreadsheet one person maintains. It works until the first customer complaint or the first second-party audit. **En corto** - Line checks happen on a phone, with photo and time tied to the point. - Suppliers are approved by criticality, not all the same. - Non-conformities have an owner and closure evidence. - The auditor's dossier is exported rather than compiled. **Approving by criticality** — A supplier who can stop the line needs a different file from a consumables supplier. ## Goods-in is where the money is saved Catching a raw material problem at goods-in costs a return; catching it on the line costs a batch; catching it at the customer costs the complaint and the reputation. A goods-in check with evidence moves the finding to where it is cheapest. ## Batch traceability When a complaint lands, the question is always the same: which raw material went into that batch, what checks were done and who did them. If that is dated and evidenced, the answer takes hours. If it is on paper, it takes days and comes with doubts. > [!WARNING] > Digitising a checklist by copying all forty points from paper is the classic mistake: if it takes twenty minutes, it gets filled in from memory at the end of the shift and does not work as evidence. ## Frequently asked questions **Does it help with an IATF or ISO audit?** For the documentary side yes: dated evidence, supplier control and corrective action follow-up with closure. **Can it be used on the line, with gloves and no signal?** It runs from a phone. Without signal it is worth checking it uploaded before closing the shift. **Can I request different documents by supplier criticality?** Yes, one process per category. That is precisely what is recommended. **What about haulier documentation?** Same circuit: requested, expires, warns. It is one of the most commonly forgotten. ## Ejemplos **A customer complains about a batch and asks for full traceability in 48 hours.** - Filters by batch and pulls that shift's checks with their photos - Attaches the certificates of the raw material that went in - Adds the non-conformity raised and its action plan → A documented answer within the deadline, which is what stops the complaint escalating. **A client audit asks for evidence of plant control over the last six months.** - Checks the period's records with their dates - Provides the log of real operations, not the procedure - Records what was handed over → The control moves from assertion to evidence and the audit is prepared in an afternoon. **A client asks for the traceability of a specific batch.** - Checks that batch's file → You answer per batch rather than per catalogue. **A supplier certificate expires with material on the floor.** - Records expiries per supplier → The warning arrives before producing with it. **The trace breaks between production and despatch.** - Ties the batch produced to the outgoing delivery note → The batch is followed to the customer. **A problem must be contained and nobody knows what shipped.** - Checks which batches went to which customers → Those affected are warned rather than the whole base. **Each shift records differently.** - Uses the same form for everyone → The history is comparable. **Plant sheets are written up at the end of the day.** - Records at the moment → The data is exact rather than reconstructed. --- --- id: KB-CS-004 url: https://app.codecontract.io/help/use-cases-by-sector/logistics-and-transport idioma: en categoria: casos-por-sector subcategoria: logistica audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-003, KB-CR-005, KB-CF-001] citadoPor: [KB-CS-030, KB-CS-008] enLaApp: https://app.codecontract.io/trackline --- # Logistics: hauliers up to date and deliveries with proof _Provider documentation that does not lapse quietly and deliveries you can prove._ **Responde a:** haulier and agency documentation · digital delivery notes and proof of delivery · logistics provider document control · export and customs documentation · digital CMR with evidence In logistics the documentary risk cuts both ways. Inbound: if a haulier operates with lapsed insurance and there is a claim, the problem is yours. Outbound: if you cannot prove you delivered, the goods count as undelivered. **En corto** - Each provider with their own file and expiries tracked. - Proof of delivery is signed on a phone, at the dock. - Incidents are logged with a photo on the spot, not on the way back. - International paperwork is requested before the lorry leaves. **Where a notice to a haulier gets lost** — Email works worse in this sector than in any other: people are on the road and read their phone. ## Providers: what to hold and renew | Document | Why | Expires | | --- | --- | --- | | Transport operator licence | Without it they cannot operate legally | Yes | | Goods in transit insurance | It covers what you ship, not their own | Yes, annually | | Social security registration | Liability in case of an accident | Periodically | | ADR certificates where applicable | Dangerous goods: no loading without it | Yes | ## Proof of delivery A paper note signed and then riding in the cab for three days is evidence that arrives late and sometimes never. Signed on a phone at unloading, with the time and a photo of the goods, it settles the argument before it exists. > [!NOTE] > Channel matters more here than anywhere else: people who drive do not read email. WhatsApp and SMS get far higher response rates. ## Frequently asked questions **Does the haulier need to install anything?** No. They open a link on their phone, sign or photograph, and that is it. **Does it work for customs paperwork?** For gathering it and keeping it dated, yes: certificates of origin, health certificates and authorisations go through the same circuit. **Can I control documentation by country?** Yes, one process per destination: requirements differ and cramming them into one makes onboarding harder. **What if the driver's phone is dead?** The delivery can be recorded later from the same link, though the signing time will be the real one, not the unloading time. ## Ejemplos **A customer says a delivery never arrived and claims the value of the goods.** - Opens the delivery and shows the signature with its time - Attaches the photo taken at unloading → The claim closes the same day, with evidence the other side can verify. **A carrier goes out with expired training and the client spots it at the gate.** - Records expiries per person and per vehicle - Checks the status before assigning the load - Warns with the lead time the renewal needs → The job does not go out with a gap and renewal happens before it hits the rota. **A client disputes a delivery and there is no proof.** - Keeps evidence of every delivery in your own archive → You answer with proof rather than a status. **The evidence lives in the partner's app.** - Collects and stores what they provide → Proof stops depending on another system. **Work is subcontracted to somebody not current.** - Checks their file before placing a load → The gap shows before the job. **The claim arrives months later.** - Keeps evidence beyond the closing of the order → The answer exists when it arrives. **Each partner sends evidence in a different format.** - Requests specific documents to a single destination → What is received is comparable. **There is a dispute about the condition goods arrived in.** - Records the condition at each handover → The dispute closes on data. --- --- id: KB-CS-005 url: https://app.codecontract.io/help/use-cases-by-sector/law-and-advisory-firms idioma: en categoria: casos-por-sector subcategoria: legal audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-006, KB-CO-001, KB-CS-002] citadoPor: [KB-CS-009] enLaApp: https://app.codecontract.io/consigne --- # Law and advisory firms: stop chasing your clients _Client onboarding, signed engagements and paperwork that arrives without phone calls._ **Responde a:** software for law firms · collect client documentation without chasing · sign engagement letters remotely · KYC and anti-money laundering documentation · document management for advisory firms In a firm, the unbillable part is chasing clients for what you need. It is also the part both sides like least: you because it is the third call, and the client because they cannot remember what you asked for or where they left it. **En corto** - Client onboarding is requested once and chased automatically. - The engagement letter is signed remotely before work starts. - Anti-money-laundering paperwork is dated. - Each matter is a case, so nothing sits loose in an email thread. ## Onboarding, where the time goes A typical onboarding is six to ten documents: identification, beneficial ownership, powers of attorney, recent filings, deeds. Requested by email they arrive in instalments and mix into the thread. Requested as a process, each has its own slot and the client can see what is missing. ## The engagement letter, before the work It is the one most often signed late and the most awkward to chase. Sent for signature from the same circuit as the paperwork — and with an advanced signature, because that is where disputes happen — it is settled the same day instead of hanging until invoicing time. > [!NOTE] > With sole traders and small clients, WhatsApp works far better than email. Switching channel on the first reminder is usually enough to unblock things. ## Anti-money laundering What an inspection reviews is not only that you hold the identification: it is that you asked for it, when you asked, and what they provided. A dated case answers that; a folder of PDFs answers only the first half. ## Frequently asked questions **Does the client have to register?** No. They open a link and upload their documents from a phone. **Can I use one process for every client?** One per type usually works better: you do not ask a company for the same things as an individual. **Does it work for the matter file itself?** Yes: each matter is a case with its documents, its data and its dated history. **What if the client sends the wrong document?** They upload again with the same link and both versions remain, each with its date. ## Ejemplos **An advisory firm onboards fifteen clients in January and each onboarding needs eight documents.** - Runs the onboarding process for all fifteen at once - Lets the reminders go out on their own, the second by WhatsApp - Sends the engagement letter for signature as soon as the paperwork is complete → A hundred and twenty documents gathered without a single phone call, and fifteen engagements signed before work starts. **An advisory firm with three hundred clients spends the first week of every month chasing documentation.** - Launches the request to everyone with the same template - Lets the reminder go out on its own - Checks what is missing per client rather than per inbox → The first week of the month is recovered and by the 5th you know exactly who is missing. **A client asks what they are missing and it has to be checked by hand.** - Shows them their own outstanding list → They answer without a phone call. **A client's documentation lives in the inbox of whoever handles them.** - Gathers the file in a shared place → The answer does not depend on who is in. **A client leaves and everything of theirs must be handed over.** - Checks their complete file → The handover is prepared in hours. **The client sends through four different channels.** - Agrees a single delivery channel → Deliveries stop getting lost. **A client document expires and nobody notices.** - Records expiries per client → The warning arrives before it bites. **Every close chases the same things from the same people.** - Reuses the process from one period to the next → The second close costs a fraction. --- --- id: KB-CR-001 url: https://app.codecontract.io/help/use-cases-by-role/quality-manager idioma: en categoria: casos-por-rol subcategoria: calidad audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CS-002, KB-TL-001, KB-SC-001] citadoPor: [KB-CR-002, KB-CR-004, KB-CR-019, KB-CR-005, KB-CR-007, KB-CS-003, KB-CF-001] enLaApp: https://app.codecontract.io/trackline/schemas --- # Quality: approving suppliers and never letting anything expire _Risk-based approval, expiry control and non-conformities with full traceability._ **Responde a:** track supplier certificate expiry dates · supplier approval by risk category · non-conformity management with traceability · digital quality inspection checklist · software for a quality manager Quality work has two halves that get in each other's way: one is documentary — approving, filing, renewing — and the other is fieldwork — inspecting, detecting, correcting. The first eats the time of the second, and the second is the one that adds value. **En corto** - Approval paperwork is requested automatically, with whatever each risk category requires. - Expiry dates warn before they lapse, not when the auditor finds them. - Every non-conformity has an owner, a deadline and a closure with evidence. - The audit dossier is exported, not compiled. ## Approve by risk, not by habit Not every supplier deserves the same file. A critical supplier — one whose failure stops your line or compromises your product — needs more documentation and more frequent review than an office stationery supplier. One process per category solves this without anyone having to remember. | Category | What is required | Review frequency | | --- | --- | --- | | Critical | Standard certification, second-party audit, contingency plan | Annual, with an interim review | | Significant | Certification, technical data sheet, insurance | Annual | | General | Tax registration and insurance | At onboarding and on change | _Over-classifying costs time; under-classifying costs an incident._ ## Expiry is the failure that repeats most A complete file in year one says nothing about year two. Almost every audit finding about supplier documentation is an expired certificate, not a missing one. With an expiry date on each document, the renewal is requested before there is a gap — and the gap is exactly what gets audited. ## Non-conformities that actually close A non-conformity with no owner and no deadline is an email. Treated as a case — who raises it, who must act, what evidence closes the action and on what date — it stops depending on somebody remembering, and the history is there for the management review. > [!NOTE] > What makes a corrective action credible to an auditor is the dated closure evidence, not the description of what was intended. ## Frequently asked questions **Can I have different requirements per product family?** Yes. One process per family or risk category, each asking for its own set. Designed once, run at every onboarding. **How do I keep the history of a long-standing supplier?** Each renewal stays as a dated delivery within the same supplier, so you see the whole sequence and not only the current document. **Does it work for plant inspections?** Yes, as a digital checklist with evidence. What it adds over paper is that the photo and the time are tied to the point inspected. **And for the management review?** The data is already there: approved suppliers, expiries, open and closed non-conformities with their deadlines. Nothing to reconstruct by hand. ## Ejemplos **A quality manager inherits 120 suppliers in a spreadsheet and has no idea which are up to date.** - Classifies by risk: 12 critical, 30 significant, the rest general - Runs the approval process on the first 42, with expiry dates - Lets the expiry alerts run the calendar from then on → Within three weeks she knows exactly what is missing and from whom, and stops opening the spreadsheet. **A certificate expires and the supplier keeps delivering.** - Records expiries and warns in advance → Renewal happens before the next order. **Approval is rebuilt from scratch for every supplier.** - Saves the process as a template → The second supplier takes minutes. **A client audits and three suppliers' documentation is missing.** - Checks everyone's status before the visit → The gaps close with time to spare. **Approval happens and nobody reviews afterwards.** - Schedules the periodic review → The approval stays true. **Chasing suppliers takes half a day a week.** - Requests and chases automatically → The half day is recovered. --- --- id: KB-CR-002 url: https://app.codecontract.io/help/use-cases-by-role/purchasing-department idioma: en categoria: casos-por-rol subcategoria: compras audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-TL-001, KB-CO-001, KB-CR-020] citadoPor: [KB-CR-014, KB-CR-008, KB-IN-001] enLaApp: https://app.codecontract.io/contacts --- # Purchasing: onboarding a supplier without chasing them _Onboarding with complete paperwork, signed contracts and expiries under control._ **Responde a:** supplier onboarding documentation · how to request a tax clearance certificate from a supplier · track supplier contracts and agreed terms · validate tax paperwork before paying a supplier · software for a purchasing department Onboarding a supplier is one of those tasks that looks like five minutes and takes three weeks: you request six documents by email, four come back, the fifth is expired and the sixth does not arrive until you phone. And meanwhile the purchase order cannot be issued. **En corto** - One onboarding process that asks for everything at once and chases what is missing. - The framework contract is signed from the same circuit, with nothing printed. - Insurance and certificate expiries warn on their own. - Before paying, the tax paperwork is validated and dated. ## What to ask for at onboarding - Tax details and clearance certificates from the tax and social security authorities. - Liability insurance, with its expiry date. - Bank details, which are better requested as data than as a loose PDF. - Accepted terms: payment periods, quality policy, confidentiality clauses. - Whatever your sector requires: certifications, approvals, licences. > [!IMPORTANT] > Bank details requested over email are the classic vector for invoice fraud: someone intercepts the thread and sends a different account number. Asking for them inside a circuit with a personal link and a record of who supplied them closes that door. ## The contract, in the same circuit Usually the document onboarding and the framework contract signature take separate paths: one by email and one through a signing service. Putting them in the same process, as two phases, means the contract does not go out for signature until the paperwork is approved — which is the correct order and almost never the one followed. ## Before paying Checking that the tax clearance certificate is still valid at the moment of payment, rather than at onboarding, is what avoids joint liability. With the expiry date on record, that check stops being a reminder in somebody's calendar. ## Frequently asked questions **Can I use the same process for every supplier?** You can, but one per type usually works better: a services supplier is not asked the same things as a materials supplier or a haulier. **What about suppliers we already work with who have no file?** Run the process on them anyway. Because it is a link and not a portal sign-up, friction is low and most reply. **How do I handle annual renewals?** With the expiry date on each document. The alert fires before it lapses and you can re-request only what expires, not the whole onboarding. **Does it integrate with our ERP?** There is a public API: onboarding can be triggered from the ERP and the outcome returned to it when the file closes. ## Ejemplos **Purchasing needs to issue an urgent order to a new supplier and onboarding normally takes two weeks.** - Runs the onboarding process with its two phases: paperwork and contract - The supplier uploads everything from a phone the same day - The contract goes out for signature as soon as the paperwork is approved → The order is issued in 48 hours instead of two weeks, and with a complete file rather than in spite of one. **Supplier onboarding takes weeks of emails.** - Launches the process and lets it chase itself → Onboarding closes without chasing. **Each buyer asks for different documents.** - Shares a single template → The supplier receives a coherent request. **Purchases are made from a supplier with no file.** - Launches onboarding with the first order → No supplier gets in without a file. **Nobody knows which suppliers are current.** - Checks everyone's status at once → You buy knowingly. **A supplier asks what they are missing.** - Shows them their own list → They answer for themselves. --- --- id: KB-CR-003 url: https://app.codecontract.io/help/use-cases-by-role/human-resources idioma: en categoria: casos-por-rol subcategoria: rrhh audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-001, KB-CO-002, KB-TL-001, KB-CR-009] citadoPor: [KB-CR-012, KB-CR-016] enLaApp: https://app.codecontract.io/consigne/new --- # Human resources: contracts, onboarding and signed policies _Sign the contract before day one, collect what is missing and keep training current._ **Responde a:** sign employment contracts remotely · employee onboarding documentation · how to collect signatures on internal policy from all staff · track expired mandatory training · HR software for document signing An onboarding is two things at once: papers the company has to get signed, and papers the person has to provide. They travel in opposite directions, which is why they usually live in two different places — and why something is always missing on Monday. **En corto** - The contract is signed remotely before day one, with proof of who signed. - The documents the person provides are requested in the same circuit. - Internal policies are signed in bulk, with an individual record for each. - Mandatory training warns before it expires. ## What goes out to the person Contract, annexes, data protection notice, code of ethics, confidentiality agreement, equipment handover. All of it can go in a single signature request with several documents, so the person signs it in one sitting instead of receiving five emails. > [!NOTE] > The contract is worth an advanced signature with an SMS code: it is the document most likely to end up disputed, and the hardest to defend without mobile verification. ## What comes from the person - Identity document and social security number. - Qualification or licence if the role requires one. - Background check where the role legally requires it. - Bank details and tax withholding form. - Medical clearance, where applicable. ## Internal policies, and why the dates matter When you have to demonstrate that someone knew the code of ethics or the systems usage policy, what counts is the date they accepted it and the proof it was that person. An email saying "policy attached" does not demonstrate it; a signature with its record does. ## Training that expires Health and safety, food handling, data protection, working at height: most have a validity period. Recorded with their expiry date, the alert arrives before the person loses their authorisation — which in an inspection reads as non-compliance. ## Frequently asked questions **Does it work for offboarding as well as onboarding?** Yes, and it is often forgotten: final settlement, equipment return, confidentiality reminder. Same circuit, other direction. **Can I send one policy to the whole workforce at once?** Yes, in batches. Each person gets their own link and their individual signature is recorded with its date, which is what you need if it is ever questioned. **Does the employee need an account?** No. They sign from their phone with their own link, without registering. **How do I keep the history of a ten-year employee?** Every signed document and every training record is dated inside their file, so the full sequence is available without digging through old emails. ## Ejemplos **A company is onboarding eight people on the same Monday and needs every contract signed beforehand.** - Sends one signature request per person with contract, annexes and policies together - Sets advanced signature on the contract and an automatic reminder after 24 hours - Requests the documents each person must provide in parallel → By Friday all eight are signed and the paperwork is complete, with nothing printed and nobody phoned. **A contract is signed on the first day of work.** - Sends it for signature before the start date → Onboarding starts complete. **A policy is emailed and nobody signs it.** - Sends it for signature and tracks the status → You see who is outstanding without asking. **A worker's documentation expires.** - Records expiries per person → The warning arrives before it bites. **Ten people are hired for a campaign.** - Launches the same process to all ten → Bulk onboarding does not consume the week. **Somebody leaves and their documentation is half done.** - Closes the file when processing the departure → The history ends complete. --- --- id: KB-CR-004 url: https://app.codecontract.io/help/use-cases-by-role/compliance idioma: en categoria: casos-por-rol subcategoria: compliance audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-CO-004, KB-SC-003] citadoPor: [KB-CR-006, KB-CR-007, KB-TZ-001] enLaApp: https://app.codecontract.io/settings/audit --- # Compliance: individual evidence, not a circular _Dated, individual acceptances, third-party screening and audit-ready evidence._ **Responde a:** prove an employee accepted the code of ethics · third-party compliance and ESG screening · evidence for a compliance audit · compliance training records · conflict of interest declarations A compliance programme is judged on what it can demonstrate, not on what it says it does. And the gap between the two is almost always in the same place: emailing a circular to the whole workforce is an action; holding each person's individual, dated acceptance is evidence. **En corto** - Every acceptance carries a name, a date and proof it was that person. - Third parties are screened with a file, not a spreadsheet. - Periodic declarations are re-issued automatically each year. - The auditor's dossier exports with the dates included. ## Acceptances that work as evidence Code of ethics, anti-bribery policy, gifts policy, systems usage, whistleblowing channel. They all share one requirement: you must be able to demonstrate that a specific person accepted it on a specific date. An individual signature does that; an email read receipt does not. ## Third parties: the most neglected point Liability does not stop at your own front door. The suppliers, distributors and agents you work with are part of the perimeter, and demonstrating that they were screened — and against what criteria — is what gets asked for when something goes wrong. | What you ask the third party for | What it is for | | --- | --- | | Acceptance of the group code of ethics | Extends the standard beyond your own workforce | | Beneficial ownership declaration | It is what gets reviewed when a conflict surfaces | | Conflict of interest declaration | Renewed annually, not just at onboarding | | Their own certifications and policies | Supports the ESG criterion with documents, not assertions | > [!WARNING] > Declarations do not last forever. A conflict of interest declaration signed four years ago says nothing about the current situation, and that date is exactly what an investigator looks at. ## Training: record that it happened, not that it was offered Same as with policies. The useful evidence is not the training material or the invitation: it is the list of who completed it, with dates, signed by each of them. ## Frequently asked questions **How do I prove someone accepted a specific policy?** With their individual signature on that document, carrying its date and the record of how it was signed. That is what you produce if it is ever disputed. **Can I re-issue declarations automatically each year?** Yes, by scheduling the send. It goes only to whoever is due, without rebuilding the circuit. **What if an employee refuses to sign?** The refusal is recorded with their reason, which for programme purposes is also evidence: it is on record that they were asked and what they answered. **Does it help evidence the whistleblowing channel?** For the documentary side yes: communication of the channel, acceptance of the policy and traceability of actions. The channel itself is a separate thing. ## Ejemplos **A compliance audit asks for proof that all 140 employees accepted the updated code of ethics.** - Filters the signatures on that document - Exports the list with each acceptance's name and date - Flags the four outstanding and who has been reminded → Individual, dated evidence for 136 people, instead of an email sent to a distribution list. **A circular is sent and everyone is considered trained.** - Asks for individual signature and tracks status → The evidence is per person. **An auditor asks for evidence and is shown the sent email.** - Shows who signed and when → The control moves from assertion to evidence. **Training repeats yearly and the send is rebuilt.** - Reuses the previous year's process → The campaign is prepared in an afternoon. **Somebody joins mid-year and receives nothing.** - Launches the process at onboarding → Nobody is left out. **Nobody knows who is still to sign.** - Checks the status per person → Only those outstanding are chased. --- --- id: KB-CR-011 url: https://app.codecontract.io/help/use-cases-by-role/when-you-are-the-only-one-who-knows-how-it-works idioma: en categoria: casos-por-rol subcategoria: operaciones audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-005, KB-MA-011, KB-CR-017] citadoPor: [KB-CR-015, KB-TD-014, KB-PS-015] --- # When you are the only one who knows how it works _Being indispensable is not a comfortable position: it means never being able to fall ill._ **Responde a:** i am the only one who knows how to do this · cannot take holiday because of work · documenting what only i know · spreading knowledge from one role In many companies there is one person who knows what each client wants, which supplier runs late, where every paper is and what to do when an inspector turns up. They are usually proud of it and usually exhausted, because they cannot be away two weeks without something falling over. ## Where that knowledge lives today | Where it is | What happens if you are away | | --- | --- | | In your head | It stops until you are back | | In your inbox | It exists, but nobody can reach it | | In a sheet only you understand | Someone else opens it and cannot read it | | In each matter's file | Anyone can carry on | > [!IMPORTANT] > The first three rows are the same thing in different disguises: information that only works with you present. Moving to the fourth is not about documenting more, it is about changing where the work happens. ## What to do, and in what order 1. **Get conversations out of your personal inbox** — What is discussed with a supplier belongs in their file. It is the highest-yield change. 2. **Write the why, not just the what** — "We text this client because their email filters us" beats a twenty-page manual. 3. **Let the system do the repetitive part** — Chasing and expiry warnings do not have to live in your memory. 4. **And test it by leaving** — One day. Whatever breaks points exactly at what still needed writing down. > [!WARNING] > Beware the line "things are complicated here". Sometimes it is true; often it just means nobody has tried writing them down. Write one and find out. ## What you gain The usual reading is that this makes you dispensable. In practice the opposite happens: whoever leaves the work in order stops being the person who fights fires and becomes the one who decides. And can go on holiday with the phone off. **En corto** - The file, not your memory. - The reasoning written down, even in one line. - And a real absence test before one is forced on you. > [!NOTE] > If someone on your team is in this position, the problem is not theirs: it is the organisation's. And it is fixed the same way, starting by getting conversations out of personal inboxes. **Where do I start with no time?** One process, the one you get interrupted about most. The rest follow. **What if nobody else wants to learn?** They do not need to learn: they need to be able to look and carry on. **How long does it take?** Weeks to feel it, months for it not to depend on you. It starts paying before it is finished. ## Ejemplos **An operations manager has not taken a full holiday in three years.** - Moves supplier conversations into their files - Puts expiry reminders on automatic - Tests with one day away → The team handles what comes up and she stops being the only route to the information. **Only one person knows how each file is going.** - Keeps the status visible on the platform → Anyone can answer. **They go on holiday and nobody knows what is outstanding.** - Checks what is waiting for action → Cover works without a long handover. **The knowledge lives in their inbox.** - Stores what matters in the files → The information outlives the person. **They get asked twenty times a day.** - Makes the status consultable by everyone → Interruptions drop. **If they leave, the company is blind.** - Spreads access and documents decisions → The risk stops concentrating in one person. --- --- id: KB-CR-012 url: https://app.codecontract.io/help/use-cases-by-role/someone-new-on-their-first-day idioma: en categoria: casos-por-rol subcategoria: rrhh audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-003, KB-CF-007] citadoPor: [KB-CS-033] --- # Someone new on their first day _What must be signed before they start, and what can wait until the first week._ **Responde a:** employee onboarding documents · what a worker signs on day one · staff onboarding paperwork · contract and annexes before starting Someone's first day fills up with papers signed halfway, taken home and returned two weeks later. And some of them needed signing **before** that person did anything. ## The two lists | Before starting | Can wait until week one | | --- | --- | | Contract and its annexes | Staff handbook and welcome pack | | Role-specific safety information | Non-critical training | | Equipment handover and usage rules | Access to secondary tools | | Confidentiality and data protection | Expenses policy and similar | > [!IMPORTANT] > The left column does not accept "they'll sign on Monday". If that person works, uses equipment or accesses data before signing what applies, the problem already exists and a later signature does not erase it. ## How to close it the same day 1. **Prepare the pack when the start is confirmed** — Not the day before: as soon as there is a date, prepare and send. 2. **Sign from a phone, before coming in** — Almost everything on the left can be signed from home the evening before. 3. **And what is signed in person, on a phone too** — Equipment handover is signed at handover, not in bulk at month end. > [!WARNING] > The commonest mistake with multiple starters (a season, a new shift) is assembling a pack per person by hand. It is the perfect case for launching the same process to everyone at once: one action, and each receives their own. ## What you must be able to show later **En corto** - What each person signed and on what date. - What training they held before starting in their role. - What equipment was issued to them and when. - And the signed versions, not the latest version of the document. The last is neglected. If the handbook changes, what that person signed was the earlier version: keeping it is what makes the signature mean anything. > [!NOTE] > The onboarding pack is almost always the same per role type. Building it once as a template turns every future start into a send, and that is where the time comes back. **What if someone has no phone or email?** They can sign on a company device; what matters is that a record exists. **Does it work for interns and temporary staff?** Yes, all the more: they turn over most and generate the most loose paper. **What if someone refuses to sign?** That is a decision to take before they start, not after. ## Ejemplos **A company brings in fifteen people for a season and signs on paper on day one.** - Launches the same pack to all fifteen when dates are confirmed - Signs equipment handover at the moment → Everyone starts with paperwork closed and without spending Monday morning on forms. **Somebody joins and nobody tells them where to start.** - Shows them the process they will use → Day one is useful. **They are given every permission for convenience.** - Gives them what their role needs → They start without seeing too much. **They are trained on the whole system at once.** - Shows them one complete process → They learn by doing something real. **They do not know who to ask.** - Points them at their area's owner → Questions reach somebody. **A week in they still have not used anything.** - Assigns them a real case from day one → Usage starts when they start. --- --- id: KB-CR-013 url: https://app.codecontract.io/help/use-cases-by-role/what-to-check-monthly-if-you-run-the-company idioma: en categoria: casos-por-rol subcategoria: direccion audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-007, KB-IC-011] citadoPor: [KB-CD-014, KB-TD-015] --- # What to check monthly if you run the company _Four things, fifteen minutes, and none of them is a dashboard._ **Responde a:** what a manager should review monthly · documentary risk indicators for management · monthly compliance review · what to check as a managing director Most documentary problems reach management once they are already an incident: a penalty, a client withholding payment, a site stopped. Almost all were visible in advance, in four figures that need looking at no more than monthly. ## The four 1. **What percentage is current** — And above all, which way it moves. 92% falling worries more than 85% rising. 2. **What has been stuck longest** — Not how many cases are open: which is the oldest. That is where the problems are. 3. **How many exceptions were approved** — The times someone let something incomplete through. If they rise, the process does not match reality. 4. **And what expires in the next ninety days** — The only thing that lets you decide with margin rather than react. > [!IMPORTANT] > The third is barely ever looked at and carries the most information. A rise in exceptions does not mean people comply worse: it almost always means the process asks for something operations cannot give, and that is fixed by changing the process. ## What you do NOT need to look at | This | Why not | | --- | --- | | Case-by-case detail | If you have to look at it, the problem is delegation, not data | | Fifteen indicators | None of them will produce a decision | | What is fine and unchanged | One line is enough | > [!WARNING] > If answering the four questions costs someone a morning of assembling, that is the month's finding. A figure that costs a morning gets calculated differently each time and stops being comparable, which was the only thing making it useful. ## The question worth asking in the meeting "What decision do you need from me this month?" If the answer is "none" two months running, either everything is going very well or the report is not describing what happens. Both possibilities deserve a conversation. **En corto** - Four figures, always the same ones. - Trend over absolute value. - And one concrete decision per meeting, or the meeting was not needed. > [!NOTE] > If you work with large clients, add a fifth: how many client audits or formal requests there were and how they were answered. It is the best leading indicator of whether the system holds. **Are fifteen minutes enough?** To look, yes. To decide what comes out of it, it depends. **Should I look myself or delegate?** Look at the four, yes. The detail, no. **What if the numbers are wrong?** That is as valid a finding as any, and it usually points at the process. ## Ejemplos **A managing director receives a fifteen-indicator report and does not read it.** - Asks for four figures with their trend - Adds the question of what decision is needed this month → Spots a rise in exceptions three months before it would have become a process problem. **The monthly review happens by asking the team.** - Checks the status already calculated → The meeting starts with data. **Everything is looked at and nothing is decided.** - Looks at what has been stalled too long → The review produces decisions. **The indicator rises and nobody knows why.** - Compares with the previous period → The change is located. **Each department presents its own version.** - Checks the same source for all → The picture is shared. **A month is skipped and the thread is lost.** - Schedules the review in the calendar → The cadence keeps itself. --- --- id: KB-CR-014 url: https://app.codecontract.io/help/use-cases-by-role/negotiating-with-the-history-in-front-of-you idioma: en categoria: casos-por-rol subcategoria: compras audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-002, KB-IC-005] citadoPor: [KB-IC-013] --- # Negotiating with the history in front of you _What changes a contract renewal: not the market price, but what happened this year._ **Responde a:** preparing a supplier negotiation · data for a contract renewal · evaluating a supplier with data · arguments for price negotiation Most renewals are negotiated with two data points: last year's price and a general feeling about whether the supplier is doing well. That feeling is usually dominated by the most recent event, which rarely represents the year. ## What to bring | Data | What it lets you say | | --- | --- | | The year's incidents, dated | "Three delays in August", not "you're unreliable" | | Documentary response time | If they have to be chased, it costs you | | How often an exception was granted | What you let through, which counts too | | And what went well | It gives you something to ask for, not just complain about | > [!IMPORTANT] > The fourth changes the tone of the whole conversation. A negotiation that only lists failures produces defensiveness; one that acknowledges what worked and names two specific things gets commitments that hold. ## How to prepare in twenty minutes 1. **Open the supplier's file and look at the year** — Not your memory of the last two months. 2. **Count, do not judge** — "Four late deliveries out of thirty-six" is a fact; "you're unreliable" is a debatable opinion. 3. **Pick two things you want changed** — Two. Nobody commits to five. 4. **And decide what you offer in exchange** — Volume, payment terms, exclusivity. Without that it is a complaint, not a negotiation. > [!WARNING] > Beware recency bias. If there was a serious problem three weeks ago, it will dominate the meeting even if the rest of the year was flawless. Looking at the whole year is precisely what stops you renegotiating badly over one case. ## What the supplier should also be able to show **En corto** - How often you asked for something with an impossible deadline. - How many scope changes came from your side. - And how long you took to approve what they delivered. If both sides have that data, the conversation is much shorter and considerably fairer. And if only one side has it, that side negotiates better. > [!NOTE] > Recording incidents in the supplier's file when they happen takes a minute and is the only thing that makes this preparation possible. Reconstructing them in December from email is not. **What if they are a sole supplier?** The history still helps: not to switch, but to agree how you work together. **Should the data be shown to them?** Almost always yes: it turns an argument about perceptions into one about facts. **How often should suppliers be reviewed?** At renewal, and mid-year for the critical ones. ## Ejemplos **A buyer enters a renewal convinced the supplier is failing, based on a recent incident.** - Looks at the full year: four incidents in thirty-six deliveries - Asks for two specific changes and offers payment terms → Closes the renewal with concrete commitments instead of an argument about perceptions. **Negotiation happens without knowing how often the supplier failed.** - Checks their history before the meeting → The conversation happens with data. **The supplier claims they always deliver on time.** - Shows the delivery history → The argument closes by looking. **Two suppliers are compared by eye.** - Checks both histories → The comparison is honest. **A contract is renewed without reviewing the year.** - Reviews the history before renewing → Renewal is decided on a basis. **The supplier asks for a price rise without justification.** - Cross-checks against what was delivered and missed → The negotiation starts from facts. --- --- id: KB-CR-015 url: https://app.codecontract.io/help/use-cases-by-role/teaching-this-to-someone-in-twenty-minutes idioma: en categoria: casos-por-rol subcategoria: operaciones audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-005, KB-CR-011] citadoPor: [KB-CR-017] --- # Teaching this to someone in twenty minutes _What to cover, what to skip, and in what order, so they start using it today._ **Responde a:** training a colleague on the platform · how to explain the system to someone new · short training session · getting the team to learn it Long training does not work: it is forgotten before it is needed. What works is twenty minutes on that person's real work, and having them leave having actually done one thing. ## The twenty-minute script 1. **Five minutes: where their own material is** — Their inbox, their files, their outstanding items. Nothing about the general structure. 2. **Five minutes: searching for something they need often** — Let them search, in their own words. It is what sticks most. 3. **Five minutes: doing one thing end to end** — Uploading one of their documents, sending a request, answering something. 4. **And five minutes: what to do when something is off** — Who to ask and where to look. It prevents silent abandonment. > [!IMPORTANT] > The fourth block is most often skipped and determines whether the person comes back. Someone who gets stuck and does not know who to ask stops using the tool without telling anyone, and that surfaces weeks later. ## What NOT to cover on day one | Not this | Why | | --- | --- | | The full folder and project structure | They will not use it today and it eats the session | | Configuration options | They are not theirs | | Everything the platform can do | It makes it feel complicated | | The rare cases | They will come up, and then get solved | > [!WARNING] > And do not do it on someone else's screen. Have them sit at their own session with their real files: half of what is learned is where their own things are, and that does not transfer by watching. ## The following week **En corto** - A ten-minute refresher after four or five days. - Based on their questions, not your script. - And looking at what they actually did, which is usually less than they say. That short refresher pays off more than doubling the initial session: it lands exactly when the person has hit their own questions. > [!NOTE] > If someone needs to learn much more than this to do their job, the process is probably built more elaborately than necessary. Training complexity is a good indicator of process complexity. **What about people who resist?** Start with what annoys them, not with what interests you. **Is a manual needed?** One page with four things and who to ask. A long manual goes unread. **And for someone who only signs?** Two minutes: it arrives, they open it, they sign. Nothing else needed. ## Ejemplos **A company runs a two-hour session for ten people and nobody uses it afterwards.** - Switches to twenty minutes each on their real work - Adds a ten-minute refresher after five days → Eight of the ten are using it within a month, with no further training. **The whole system is explained in twenty minutes.** - Shows one complete process end to end → Something usable is learned. **It is taught with made-up data.** - Uses a real case from their work → They recognise what they see. **It is explained and nobody touches anything.** - Lets the person do it → Learning happens by doing. **It is taught and a week later they are not using it.** - Assigns them their own case that day → Usage starts with the training. **The same explanation is repeated for every person.** - Documents the process → The second person learns on their own. --- --- id: KB-CR-016 url: https://app.codecontract.io/help/use-cases-by-role/if-you-run-health-and-safety idioma: en categoria: casos-por-rol subcategoria: rrhh audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-003, KB-CN-005] citadoPor: [KB-CF-017, KB-LE-018] --- # If you run health and safety _A role where nearly everything done must be provable, and nearly everything depends on third parties._ **Responde a:** health and safety documentation · evidencing worker training and fitness · contractor coordination · signed ppe issue Running health and safety has an uncomfortable asymmetry: when everything goes well nobody notices, and when something happens every piece of paper gets reviewed backwards. And much of that paper is not produced by you — it has to come from the prevention service, the insurer, the training provider or the contractor coming on site. ## The four things reviewed after an accident | What | It must date from | Where it usually fails | | --- | --- | --- | | Role-specific training | Before they started that task | It happened, but the certificate arrived later | | Medical fitness | Valid that day | It lapsed and nobody held the alert | | Equipment issue | With the real issue date | Signed in bulk weeks later | | Information and coordination with third parties | Before they set foot on site | It was agreed by phone | > [!IMPORTANT] > In all four, what is checked is not that the document exists: it is that **its date precedes the event**. A perfect training certificate issued three days after the accident evidences nothing — and that is exactly what happens when administration runs behind operations. ## What pays off most in this role 1. **Warnings with margin for everything that expires** — Fitness, training, equipment inspections. It is half the job and can be fully automated. 2. **Signing at the moment, from a phone** — Equipment issue and role information, on the day they happen. 3. **Contractor documentation, checked before access** — If access does not depend on it, it becomes a decorative formality. 4. **And coordination minutes closed as the meeting ends** — With actual attendees, not the invitation list. > [!WARNING] > The point that is most uncomfortable to say out loud: if the system you build demands more than operations can deliver, people bypass it and you are left with signed papers that do not reflect what happens. That is worse than not having them, because it creates false confidence — and in an investigation, a record that does not match the facts does more damage than an acknowledged gap. ## How the work gets defended **En corto** - With dates preceding the event, not with volume of paperwork. - With exceptions recorded and closed, not hidden. - And with a trail of who was informed and when. The second is what marks real management: showing there was an exception, who authorised it and until when, protects far more than a flawless file nobody believes. > [!NOTE] > Specific obligations on training, health surveillance and coordination depend on the sector, the activity and the size, and they get updated. **Confirm what applies to you with your prevention service**; this describes how to keep findable and dated what that service and an inspector will ask for. **What if training is delivered by another company?** Have them supply the certificate by their link: it arrives sooner and lands in the person's file. **Must PPE issue records be kept?** Yes, with the real date: it is among the first things reviewed. **Can I give access to my prevention service?** Yes, scoped and read-only; it saves a great deal of email. ## Ejemplos **A safety officer signs equipment issues at month end to save time.** - Moves signing to a phone at the moment of issue - Automates fitness and training alerts → Record dates match the events again, which is the only thing reviewed afterwards. **A subcontractor comes in without current documentation.** - Checks their status before authorising → The gap shows before the gate. **A worker's training expires on site.** - Records expiries per person → The warning arrives before work is assigned. **A document is signed on site and stays on paper.** - Captures it as it is signed → The paper stops being the only copy. **Several firms coincide and nobody sees the whole.** - Checks everyone's status at once → Coordination starts from a shared picture. **A review asks about a specific day.** - Checks who was authorised on that date → You answer from the record. --- --- id: KB-CR-017 url: https://app.codecontract.io/help/use-cases-by-role/if-you-run-the-warehouse idioma: en categoria: casos-por-rol subcategoria: operaciones audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-005, KB-CN-010, KB-CR-015] citadoPor: [KB-CR-011] --- # If you run the warehouse _Everything later argued about comes through your door, and nearly always at the worst moment of the day._ **Responde a:** warehouse documentary control · goods-in what to check · rejecting a delivery documentation · warehouse manager paperwork The warehouse is where everything comes in and goes out, and therefore where half the documentation someone later demands is generated. With one peculiarity: it is generated with a lorry waiting, a driver in a hurry and often first thing in the morning. ## What to capture at the door | Moment | What is recorded | If not done now | | --- | --- | --- | | Intake | What arrives, in what condition and from which batch | It cannot be reconstructed: the lorry has gone | | Incident | Photo and description before moving anything | You argue with the supplier with no evidence | | Rejection | What is returned and why, and who brought it | You have neither the goods nor the proof | | Dispatch | What leaves, with what paperwork and to where | Forward traceability breaks | > [!IMPORTANT] > All four share one enemy: **the time it takes to reach the office**. A delivery note stacked to "process later" is one processed two days later, when nobody remembers whether the box arrived dented. Everything on this list is solved by doing it from a phone at the unloading, and is not solved any other way. ## What makes your life easier 1. **Photograph the delivery note on receipt, always** — Even if the paper gets filed later: the photo is already linked to the day and the supplier. 2. **The batch as the thread, not the order** — It is what later answers any backwards question. 3. **Record rejections exactly like acceptances** — It is the evidence that defends you, and the one hardly anyone has. 4. **And say what does not add up on the spot** — A discrepancy raised at unloading gets clarified; raised at invoicing, it gets argued. > [!WARNING] > The most underestimated point is who receives when you are not there. A seven-in-the-morning, Saturday or holiday delivery is taken by whoever is present — and if that person has no two-minute route to leave a record, nothing remains. **It is not a discipline problem, it is an access problem**: if recording requires an office computer, it will not be recorded. ## What you will be asked months later **En corto** - Exactly what arrived that day and from which batch. - Who received it and what they checked. - What was rejected and why. - And where what left went, with its documentation. All four are answered in seconds if captured at the door, and not answered if left for the office. There is no middle ground, because what is missing is not the paper: it is the moment. > [!NOTE] > If you also receive subcontractor or service visits, apply the same: who came, what they did and what documentation they brought. That is the information an insurer or an inspector asks for later, and that nobody records because "they only came to look". **What if the supplier will not wait while I record?** A photo of the note and the pallet: ten seconds and it needs no permission. **Is the weighbridge ticket enough?** As weight yes; as origin no, unless it links to the batch and the supplier. **Must I record what I reject even though it never enters?** That above all: it is the only proof of what arrived and what you sent back. ## Ejemplos **A warehouse stacks delivery notes to take to the office at day's end.** - Photographs each note and any incident at the unloading - Records rejections too → Quantity differences get resolved the same day and stop appearing on invoices. **Goods arrive and the delivery note is signed in a rush.** - Captures the note on receipt → The record is not lost at the bay. **There is a dispute about the condition something arrived in.** - Captures the condition on receipt → The dispute closes on the record. **Nobody knows what came in last week.** - Checks the goods-in record → The question has an answer. **A supplier delivers with no documentation.** - Puts on record what is missing the same day → The claim goes out while it is easy. **Material is put away and nobody records it.** - Records the location on unloading → It is located without walking the warehouse. --- --- id: KB-CR-018 url: https://app.codecontract.io/help/use-cases-by-role/if-legal-landed-on-you-without-being-a-lawyer idioma: en categoria: casos-por-rol subcategoria: legal audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-006, KB-CR-010] citadoPor: [KB-LE-016] --- # If legal landed on you without being a lawyer _In many companies contracts are handled by whoever handles other things. You need not be a lawyer, you need to not lose the thread._ **Responde a:** I handle contracts and I am not a lawyer · tracking contract renewal dates · a contract auto-renewed · where to keep company contracts It happens in almost every mid-sized company: there is no legal department, there is someone — from admin, purchasing, management — who also handles contracts. The job is not interpreting clauses; that is what the adviser is for. It is making sure nobody finds out too late about something that was written down. ## What gets lost, by frequency | What | Why it gets lost | What it costs | | --- | --- | --- | | Annexes and amendments | Signed separately, months later | Arguing from a version no longer in force | | Notice periods | They are on nobody's calendar | A renewal nobody wanted | | Contracts of whoever left | They were in their email | Discovering them when the supplier claims | | What others signed | Everyone signs their own | Not knowing what the company is committed to | > [!IMPORTANT] > The second row costs the most money and is the least visible: **a contract with automatic renewal renews itself, and the notice period expires before the contract does**. By the time someone remembers to look, the window not to renew has passed — not by weeks, sometimes by months. Which is why the date to record is not the contract's end: it is when the decision has to be made. ## The minimum that holds this up 1. **One single place holding them all, signed** — Including those someone else signed. Split across five inboxes, they do not exist. 2. **Each contract with its annexes inside** — A contract without its amendments tells a false story. 3. **Two dates per contract: decision and end** — The decision date is the one that warns; the end date only informs. 4. **And who owns each one** — Not whoever signed it: whoever will look at it when the time comes. > [!WARNING] > What surprises people the first time they tidy this up: **commitments nobody remembered turn up**. A maintenance contract signed six years ago still being charged, an exclusivity arrangement limiting who you may buy from, an extension accepted by email. It is not negligence: it is what happens when everyone keeps their own. The first inventory is uncomfortable and it is the one that saves the most. ## Where your part ends and the adviser's begins **En corto** - You: that it exists, that it is complete and that warning comes in time. - The adviser: what a clause means and what is worth signing. - And the line is always crossed the same way: when in doubt, ask before signing, not after. > [!NOTE] > None of this replaces legal advice, nor tries to: **whether a clause suits you is decided by your adviser**. What is described here is the administrative part, which is the one that goes missing on its own and causes most of the frights. **Should I keep the drafts too?** The signed version and the annexes, always. Drafts only when they explain something. **What about contracts from years ago?** Those still in force first. The rest get added over time. **Who should have access?** Fewer people than you think, and by design: not everyone needs to see everything. ## Ejemplos **A company finds a maintenance contract has auto-renewed for a third year.** - Records the decision date rather than the end date, and gives each contract an owner → The warning arrives with room to decide, which is the only thing that prevents an unwanted renewal. **Legal lands on you without being your job and nobody knows where to start.** - Inventories what contracts and deadlines exist → The starting point exists. **A deadline passes unnoticed.** - Records deadlines with warnings → The warning arrives with room to act. **Something is signed without knowing what it commits to.** - Checks with the adviser before signing → The decision is taken on a basis. **Contracts are spread across drawers and inboxes.** - Gathers everything into one file → It is found without searching. **A formal request arrives and nobody knows what exists.** - Checks the file before answering → The response is prepared informed. --- --- id: KB-CR-019 url: https://app.codecontract.io/help/use-cases-by-role/if-you-run-quality-single-handed idioma: en categoria: casos-por-rol subcategoria: calidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-IC-007] citadoPor: [KB-IC-015] --- # If you run quality single-handed _A system designed for a department, held up by one person who also does three other jobs._ **Responde a:** I am the only quality manager · running iso 9001 alone · no time to maintain the quality system · quality in a small company In most mid-sized companies, quality is one person. Often the same one covering health and safety, environment and part of purchasing. The system, meanwhile, is written as if a team stood behind it — and that gap is to be managed, not denied. ## Where the time goes, and what can be taken off your plate | Task | Who can really do it | What is left for you | | --- | --- | --- | | Chasing supplier documentation | The system, with alerts | Looking at the exceptions | | Remembering expiry dates | The system | Deciding what to do when they fire | | Recording what happens on the floor | Whoever is on the floor | Making it easy to record | | Analysing causes and closing actions | You | The one thing that cannot be delegated | | Preparing the audit | It prepares itself if the above works | Reviewing and presenting | > [!IMPORTANT] > The trap of the job is the third row, and it is hard to admit: **when recording something is awkward, you end up doing it yourself, late and second-hand**. Someone tells you on Thursday what happened on Monday and you write it down from their memory. That record exists, but it no longer describes what happened — it describes what is remembered three days later. Lowering the friction of recording — two fields and a photo from a phone — is not about comfort: it is what makes the data real. ## The three things that hold the system up when there is nobody else **En corto** - Let the repetitive part alert on its own: expiries, renewals, missing documents. - Let recording be done by whoever sees the problem, not by whoever writes the report. - And let evidence be produced by working, not in an afternoon of collecting. > [!WARNING] > There is something about the job nobody explains at the start: **if the system works, it becomes invisible, and so does your work**. Nobody thanks you for the audit with no findings or the certification renewed without drama. It is worth keeping a short list of what was avoided — what was caught in time, what never reached a client — because at the annual review that list is the only thing translating your work into something management can see. ## What to do when you genuinely cannot keep up 1. **Prioritise by risk, not by standard** — What can harm a client comes before what a document requires. 2. **State in writing what will not get done** — An email to management turns an omission into their decision. 3. **And take what slipped to the annual review** — It is the only forum where that can turn into resources. > [!NOTE] > What exactly your certification scheme requires, and what latitude each requirement allows, is set by the applicable standard and your auditor. **Check with them or your adviser**; here it is about holding the system up without burning out the person who runs it. **Can it all be run without help?** It can be held up; doing it all by hand cannot. The difference is what is automated. **What if nobody records anything?** It is nearly always friction, not indifference: count the steps to record. **How do I ask for more resources?** With what was avoided and what went undone, in writing, once a year. ## Ejemplos **A quality manager logs floor incidents days later, from hearsay.** - Reduces recording to two fields and a phone photo by whoever sees it → Incidents get logged the same day and the analysis starts from what happened, not from memory. **One person runs quality for the whole company.** - Automates the requests that repeat → Time goes on reviewing. **An audit arrives and everything has to be prepared.** - Keeps the file current through the year → Preparation is a review. **Certificates expire unnoticed.** - Records expiries with warnings → Renewal happens with time to spare. **They go on holiday and everything stops.** - Keeps the file accessible to the team → The work does not depend on one person. **Suppliers are chased one by one.** - Requests and chases automatically → Chasing stops taking up the week. --- --- id: KB-CR-020 url: https://app.codecontract.io/help/use-cases-by-role/vetting-a-supplier-you-already-work-with idioma: en categoria: casos-por-rol subcategoria: compras audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-009, KB-CL-012] citadoPor: [KB-CR-002] --- # Vetting a supplier you already work with _Asking a ten-year supplier for documents reads as distrust unless explained. And the oldest one reacts worst._ **Responde a:** asking long-standing suppliers for documents · vetting existing suppliers · the supplier takes offence at paperwork · starting to control the usual suppliers Vetting new suppliers is easy: it enters the conversation from day one and nobody argues. The problem is the other thirty — those who have supplied for years without anyone asking for a document, and who must now be emailed for five of them. ## How each one reacts | Supplier profile | How they usually react | What works | | --- | --- | --- | | Large and organised | Sends it in two days | Just ask: they have it ready | | Small and tidy | Asks what for and sends it | Explain the reason once | | Long-standing, informal | Takes it as distrust | A call before the email | | The one who does not have it | Goes quiet and stalls | Time and a realistic minimum list | > [!IMPORTANT] > The third row is the one to work on before sending anything: **for a long-standing supplier, asking for documents after ten years is not a formality, it is a message**. And the message received, unexplained, is that something has happened or that you no longer trust them. A one-minute call — «we are doing this with everyone, starting with those who do most work for us» — changes the response entirely, and it is the difference between papers in a week and a negotiation you never intended. ## How to run the campaign 1. **Start with the highest risk or highest volume** — And say so: being first reads better when the reason is given. 2. **Ask for the minimum list, not the ideal one** — Five documents get sent; fifteen open a discussion. 3. **Give one realistic deadline** — A short deadline with extensions teaches that deadlines do not matter. 4. **And say what happens if it does not arrive** — With no consequence, half of them never will. > [!WARNING] > Every vetting campaign's uncomfortable discovery: **some long-standing suppliers will not be able to provide what you ask**, and not for want of willingness. They have worked for years without that document because nobody asked. There the decision is no longer purchasing's: it is whether you keep working with them, give them time to obtain it, or accept the risk in writing. What does not work is leaving it open — because then the work continues and so does the gap. ## What the relationship gains when it is done well **En corto** - The supplier knows what you expect, which rarely harms them. - The awkward conversations at every audit stop happening. - And whoever does keep their documents current competes on equal terms. > [!NOTE] > If your own clients require you to control the chain, say so: for a supplier, «we are being asked» is very different from «we have decided to ask». It is true, it is understood and it stops them taking it personally. **Do I stop orders if they do not send it?** That is the decision to take before starting, not when it happens. **What if they have never had that document?** Case by case: sometimes another one proves the same thing. **Do I ask again every year?** Only for what expires. Repeating what does not change wears the relationship. ## Ejemplos **A company emails thirty long-standing suppliers for five documents and gets four replies.** - Calls the oldest ones first and explains it applies to everyone, starting with the main ones → Most reply within a week and the awkward conversations come down to two cases. **New suppliers are approved and existing ones have no file.** - Launches the same process to those already working with you → The criterion is the same for everyone. **A long-standing supplier has never provided anything.** - Launches onboarding as if they were new → Seniority stops being an exception. **There is a fear of upsetting a trusted supplier.** - Explains it is the same process for everyone → The request does not read as distrust. **A hundred are onboarded at once and nobody replies.** - Launches in rounds, starting with the critical ones → Progress is real from the first round. **An audit uncovers suppliers with no file.** - Checks beforehand who has no file → The gap closes with time to spare. --- --- id: KB-CR-005 url: https://app.codecontract.io/help/use-cases-by-role/operations idioma: en categoria: casos-por-rol subcategoria: operaciones audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-DI-002, KB-TL-003] citadoPor: [KB-CR-011, KB-CR-017, KB-CS-003, KB-CS-004] enLaApp: https://app.codecontract.io/trackline --- # Operations: checklists and reports that do not sit in a drawer _Shop-floor checks with evidence, incidents with an owner and validated receipts._ **Responde a:** digital checklist for operations · log incidents with photo and owner · paperless work orders · validate material receipt with evidence · digitise plant processes without development The problem in operations is not that nothing is checked: it is that the checking happens on paper, in a notebook or in a WhatsApp group, and when you need to prove it happened there is no way to. The photo is on the phone of someone who no longer works here. **En corto** - A digital checklist ties the photo and the time to the point checked. - Every incident has an owner, a deadline and closure evidence. - Material receipt is validated on the spot, not the next day. - It all happens from a phone, on the floor, without walking back to the office. ## Checks that work as evidence A paper checklist proves somebody ticked a box. A digital one with a photo proves what was seen, when, and by whom. The difference shows up the day there is a claim and you have to reconstruct what happened on the night shift. ## Incidents that actually close An incident with no owner and no deadline turns into a message nobody picks up. Treated as a case — who raises it, who acts, what evidence closes it — it stops depending on somebody remembering, and the history is there to see whether it repeats. > [!WARNING] > The classic mistake when digitising a checklist is copying it straight from paper, all forty points. If it takes twenty minutes, it gets filled in at the end of the shift in the locker room and you are back to having nothing. ## Receipts and deliveries - Validate goods against the delivery note as they are unloaded. - Photograph whatever arrives damaged before it mixes with the rest. - Sign the delivery on the driver's phone, with no paper involved. - Record who received it, at what time and in what condition. ## Frequently asked questions **Does it work without coverage on the floor?** The photo is taken anyway; what needs a connection is sending it. In dead zones it is worth checking they uploaded before closing the shift. **Can someone without an account fill it in?** Yes, as an external participant with their link. That is what you do with hauliers or contractor staff. **Can the same checks repeat every shift?** Yes, by scheduling them. Each run is its own case with its own date. **What if something was noted by mistake?** It is corrected, and the record shows who corrected it and when — which is what an audit asks for. ## Ejemplos **A plant receives a complaint about a batch and needs to show what checks were done that day.** - Opens that shift's checklists - Shows the photo for each point with its time and who did it - Attaches the incident that was raised and how it was closed → An answer the same day, backed by evidence, instead of a week reconstructing it from people's memory. **The job sheet stays in the van.** - Captures the sheet at the job itself → The month closes on what happened. **Checklists are filled in from memory at the end of the day.** - Records at the moment, from a phone → The data is exact. **A client asks you to evidence an intervention.** - Checks that job's file → You answer without reconstructing. **Each technician records differently.** - Uses the same form for everyone → The history is comparable. **Job sheets reach the office days later.** - Uploads the sheet on finishing the job → Invoicing does not wait. --- --- id: KB-CR-006 url: https://app.codecontract.io/help/use-cases-by-role/legal-department idioma: en categoria: casos-por-rol subcategoria: legal audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-004, KB-CR-004, KB-TZ-001] citadoPor: [KB-CR-018, KB-CS-005] enLaApp: https://app.codecontract.io/consigne --- # Legal: contracts that do not get lost and signatures that hold up _Centralise contracts, track expiries and have the evidence ready if you have to produce it._ **Responde a:** contract management with version control · contract expiry alerts · sign powers of attorney and minutes remotely · compile documentation for legal proceedings · client KYC documentation Legal work has a hidden half that eats the time: knowing which contracts exist, which is the current version of each, when they expire and where the proof they were signed lives. That is not advising; it is administration. And it is what can be taken off the table. **En corto** - One contract per case, with its annexes and versions in one place. - Expiry warns early, while renegotiation is still possible. - The signature comes with its evidence chain, not as a loose PDF. - If something has to be produced in proceedings, it is already assembled. **What is recorded about each signature** — The full sequence with its author and time, which is what you produce when the other side disputes it. ## Contracts: the problem is the version Whole contracts are almost never lost; what gets lost is knowing which of the four versions that went round by email is the one that was signed. With the contract and its annexes inside one case, and the signature tied to the specific version, that doubt disappears. ## Expiries and renewals A contract with automatic renewal that nobody looked at is an unwanted year. The alert has to arrive with enough margin to decide, not merely to find out: if the notice period is three months, warning in month eleven is useless. > [!WARNING] > Record the notice date as the key date, not the expiry. They are different things and the one that matters for acting is the first. ## When you have to produce What holds an electronic signature up in proceedings is not the PDF: it is the evidence chain and the timestamp, which the other side can verify independently. Having it already assembled is the difference between answering a request in a day or in three weeks. ## Frequently asked questions **Does it help gather KYC documentation?** Yes, it is the same circuit: you request from the client what the rules require, it is dated, and you do not chase it by email. **Can I sign a power of attorney or minutes remotely?** With the available signature levels, yes for internal and contractual use. Anything requiring a notary still requires one. **How do I handle annexes and amendments?** In the same case as the main contract, each with its own date. That way you see the whole sequence without opening four folders. **Can I give read-only access to someone outside the department?** Yes, with the reader role or by sharing that specific case, without granting access to the rest. ## Ejemplos **A request asks for the signed contract with a supplier and all its amendments, with proof of signature.** - Opens the contract case - Downloads the signed PDF with its evidence chain - Attaches both amendments, each with its signing date → It is answered the same day, and the other side can verify the signatures independently without asking you for anything. **A contract is signed and filed with no key dates.** - Records expiries and rollovers with warnings → Renewals stop surprising anyone. **A change is agreed by email and never reaches the contract.** - Files the agreement with the contract → What was agreed later lives with what was agreed before. **A clause is hunted across twenty contracts.** - Searches by content → It is found without opening them all. **A signer denies having signed.** - Provides the document with its evidence → The signature holds up. **A contract auto-renews without review.** - Warns before the rollover date → Renewal becomes a decision. --- --- id: KB-CR-007 url: https://app.codecontract.io/help/use-cases-by-role/executive-management idioma: en categoria: casos-por-rol subcategoria: direccion audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-CR-004, KB-CF-001] citadoPor: [KB-TL-008, KB-CR-013, KB-CF-005] enLaApp: https://app.codecontract.io/dashboard --- # Management: knowing you are up to date without asking anyone _What to check once a week to spot risk before it turns up in an audit._ **Responde a:** documentation compliance dashboard · how do I know if my company is up to date · risk from expired documentation · compliance indicators for management · visibility of contracts and expiries The question management asks is not "how does the tool work", it is "are we up to date or not". And the honest answer in most companies is "we think so", because the data is spread across four people and three spreadsheets. **En corto** - Four indicators are enough to know whether risk is building up. - What matters is not volume, it is what has been stuck. - An unattended expiry costs more than an incomplete file. - It all comes out of daily work: nobody has to be asked to report. ## The four numbers | Indicator | What it tells you | When to worry | | --- | --- | --- | | Incomplete cases | Work started and not closed | If it grows week on week | | Expired documentation | Live risk, right now | Any non-zero number on anything critical | | Expiring within 60 days | Work coming your way | If nobody has started requesting it | | Average time to close | Whether the process works | If it rises without volume rising | _The second is the only one you read without context: an expired document at a critical supplier is a problem today._ ## Why volume misleads Two hundred open cases says nothing on its own: it may just be a busy company. What does say something is how many have been stuck for over a month waiting on the same person. That is the number that predicts the problem. > [!NOTE] > If the team has to prepare a report for management to see this, the system is set up wrong. The data should come out of the work, not out of a meeting. ## Signing without being the bottleneck Management is usually the last signer on everything, and therefore the point where things pile up. Signing from a phone, notified when it arrives rather than when somebody remembers to chase, takes calendar days out of processes that were only waiting on a signature. ## Frequently asked questions **Do I need to log in daily?** No. Once a week is enough if the expiry alerts are configured properly: anything urgent reaches you on its own. **Can I see everything without being able to change anything?** Yes, with the reader role. Though management usually wants administrator, so as not to depend on someone else for a change. **Can it be exported for the board?** Yes. And exporting beats screenshots: the export carries the dates. **What do I look at first if I only have five minutes?** Anything expired at critical suppliers or people. It is the only indicator that is a problem today rather than a trend. ## Ejemplos **A board asks whether the company is exposed on supplier documentation.** - Checks the number of expired documents at critical suppliers: two - Confirms the renewal was already requested a week ago - Exports the status with its dates → An answer with a number and a date in five minutes, instead of "we will look into it and come back to you". **The team is asked whether everything is up to date.** - Checks the status without asking anyone → The answer arrives there and then. **The monthly report is built by hand.** - Checks the status already calculated → The close stops taking an afternoon. **A problem is spotted once it is already large.** - Reviews what has been stalled too long → The blockage shows in days. **Decisions are taken without knowing how long closing a file takes.** - Checks the average time per process → The decision is taken with data. **Each department gives its own version of the status.** - Checks the same source for all of them → The meeting starts from a common picture. --- --- id: KB-CR-008 url: https://app.codecontract.io/help/use-cases-by-role/administration-and-finance idioma: en categoria: casos-por-rol subcategoria: administracion audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-002, KB-CD-001, KB-TZ-001] citadoPor: [KB-CR-010] enLaApp: https://app.codecontract.io/documents --- # Administration: approvals and filing without lost emails _Approvals with a trail, filing you can actually search, and licences that do not lapse quietly._ **Responde a:** archive invoices and accounting documents · internal expense approvals with an audit trail · track company licences and permits · approval workflows without lost emails · digitise administration in a small company Administration moves the most paper and is the department least likely to appear in a digitisation project. The result is familiar: approvals by email nobody can find, invoices filed by whoever received them, and licences that lapse without anything flagging it. **En corto** - An approval is a case with an owner, not an email copied to four people. - Filing is organised by matter, not by who received it. - Licences and permits warn before they lapse. - Everything is dated, which is what an accounting review asks for. ## Approvals you can find Approving a spend by email works until you have to prove who approved it. As an approval request it carries a name, a date and the document it referred to, and it is searched in one place rather than in three people's inboxes. ## Filing that still works next year The filing criterion has to be the one you will search by, not the one that was convenient when saving. By supplier and by financial year works nearly always; by who received it, never — because that person may not be around when it matters. > [!NOTE] > If automatic reading extracts invoice number, date and amount, filing stops depending on what the file was called. You search by the data, not by the name. ## Licences and permits These lapse the most quietly: an operating licence, a permit, fleet insurance. Nobody looks at them because they are not part of the daily routine, which is exactly why the alert should arrive on its own with room to renew. ## Frequently asked questions **Can I build a two-level approval?** Yes, as two phases: the second does not open until the first approves. **Does it work for mandatory tax archiving?** For keeping it ordered and dated, yes. Retention periods are configured in the retention policy. **Does it integrate with our accounting software?** There is an API: you can push the document and its data, or receive a notice when something is approved. **What if the approver is on holiday?** The approval can be reassigned to someone else, and the record shows it was reassigned and by whom. ## Ejemplos **An accounting review asks who authorised twelve expenses from the previous year.** - Filters the approvals for that period - Exports the list with name, date and the associated document → Twelve records with a name and a date, instead of searching the inbox of someone who has left. **Approvals are requested by email and get lost.** - Launches the approval with its status → You see who is outstanding without asking. **The archive lives in network folders nobody tidies.** - Centralises into files → It is found without walking the structure. **An approval is given verbally.** - Records who approved and when → The approval has a name and a date. **The same thing is approved twice just in case.** - Checks the status before resending → Nobody receives the same thing twice. **An auditor asks you to evidence an old approval.** - Checks that approval's log → You answer from the trail. --- --- id: KB-CR-009 url: https://app.codecontract.io/help/use-cases-by-role/if-you-run-hr-in-a-small-company idioma: en categoria: casos-por-rol subcategoria: rrhh audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-007, KB-CF-004] citadoPor: [KB-CR-003] --- # If you are the whole HR department _Onboarding, amendments and training for a hundred people with no team behind you._ **Responde a:** handle employment paperwork single-handed · get the whole workforce to sign amendments · track mandatory training · hr tools for a small company The problem with running HR in a mid-sized company is not difficulty: it is the volume of small things only you can do, all with deadlines, none delegable. Three of them can stop being manual. ## 1. Onboarding Contract, paperwork and first-day training are always the same. Built as a process, the person receives it on accepting the offer and arrives fully signed up. ## 2. Sends to the whole workforce An agreement amendment for a hundred and twenty people is one send, not a hundred and twenty. And tracking tells you who to phone, instead of cross-checking a list by hand. ## 3. Training that expires Health and safety, food handling, role-specific risks. Marked with their expiry, they warn two months ahead instead of surfacing in an inspection. | What eats your time today | What it becomes | | --- | --- | | Chasing onboarding paperwork | The process chases; you phone the two outstanding | | Sending amendments one by one | One send and a list of stragglers | | Keeping count of training | A warning that arrives on its own | | Finding someone's 2021 contract | A search | > [!IMPORTANT] > This handles identity documents, payslips and health data: ask for the minimum, store it where only you and the right people see it, and do not leave it circulating by email. It is the area where a slip has the most consequences for specific people. > [!NOTE] > If you start with one thing, make it onboarding: it repeats most and moves the most paper per person. **Can someone sign before they start?** Yes, and it is recommended: contract signed before day one. **What about people without a work email?** Send to their personal address or by SMS. **Can each manager's view be separated?** Yes, by team. One area head has no need to see another's payroll. ## Ejemplos **An HR manager handles 130 staff single-handed.** - Builds onboarding as a process - Sends the annual amendment as one batch - Marks training with expiry dates → Gets back the September week that used to disappear entirely into the agreement amendment. **One person handles all HR and cannot keep up.** - Automates the requests that repeat → Time goes on what needs judgement. **Onboardings arrive on the person's start date.** - Launches the process when the contract is signed → Onboarding is prepared in advance. **Documentation expires unnoticed.** - Records expiries per person → The warning arrives with room to act. **They go on holiday and everything stops.** - Keeps the file accessible to the team → The work does not depend on one person. **An inspection asks for the workforce's documentation.** - Checks each person's file → The handover is prepared in minutes. --- --- id: KB-CR-010 url: https://app.codecontract.io/help/use-cases-by-role/if-you-run-the-back-office idioma: en categoria: casos-por-rol subcategoria: administracion audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-006, KB-CC-003, KB-CR-008] citadoPor: [KB-CR-018] --- # If you run the back office _The job everything nobody else wants to chase passes through._ **Responde a:** organise company documentation · small business back office paperwork · i cannot find a client's documents · manage onboarding and invoices Everything with paper behind it passes through the back office: supplier onboarding, the client contract, whatever the accountants are asking for, the certificate needed to get an invoice paid. Almost always urgent and almost always for yesterday. ## The three that give back the most time 1. **Let onboarding ask for itself** — Suppliers and clients always need the same things. Built once, chasing stops being your job. 2. **Let expiries warn you** — Insurance, tax clearance, licences. Nobody should be carrying that in their head. 3. **Make searching actually search** — If finding a three-year-old client contract takes half an hour, the structure is wrong — or no structure is needed and searching is enough. | What you get asked | How long today | How long it should be | | --- | --- | --- | | "Send me this client's contract" | Half an hour hunting | One search | | "Is this supplier tax-cleared?" | An email and a wait | Look at it | | "I need everything on this site for the accountants" | A morning | One download | > [!WARNING] > Watch out for the email changing the bank details of a "long-standing" supplier. It is the commonest fraud against this role, and it works because it arrives in a hurry with a tone that seems normal. Confirm by phone, on a number you already had. > [!NOTE] > When someone asks you for the same thing a third time in one week, that is exactly the document worth making reachable in two clicks. **Can I give the accountants access?** Yes, read-only and scoped. They do not need to be administrators. **What about old paper files?** Scan what gets consulted, not everything. Digitising twenty years of archive is rarely finished. **Is it worth it if we are only a few?** Especially if you are few: there is nobody to delegate to. ## Ejemplos **In a forty-person company, one person handles onboarding, contracts and the accountants.** - Builds supplier onboarding as a process - Marks the expiry dates - Gives the accountants read-only access → Stops being the bottleneck for four people who ask them for things every day. **Approvals are chased by email.** - Launches the approval with its status → You see who is outstanding without asking. **The archive depends on how each person names things.** - Agrees the convention and applies it → Anyone finds the same thing. **Month end is spent hunting documents.** - Gathers the period's material into a file → The close stops being a search. **A supplier chases a payment already made.** - Checks the supplier's file → The answer comes from the archive. **Unapproved invoices pile up.** - Checks what is outstanding per owner → The chase is aimed. --- --- id: KB-CF-009 url: https://app.codecontract.io/help/use-cases-by-capability/approving-suppliers-against-your-own-criteria idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-006, KB-TL-011] citadoPor: [KB-CF-011, KB-CF-018, KB-CR-020] --- # Approving suppliers against your own criteria _Making "approved" mean the same thing whoever decides it._ **Responde a:** supplier approval criteria · when do i clear a supplier · supplier approval checklist · vendor qualification criteria Approving a supplier is not having the paperwork: it is deciding they can work with you. The difference shows on the day two people on the same team reach different conclusions with the same documents in front of them. ## What makes "approved" mean something **En corto** - Written criteria, not the judgement of whoever looks that day. - A minimum per criterion, not "must have insurance" but "insurance of at least X". - Who decides when something falls outside the rules. ## The three levels that usually suffice | Level | What it requires | Who approves | | --- | --- | --- | | Approved | Everything mandatory, current and meeting the minimum | Automatic on completion | | Approved with conditions | Something non-blocking is missing, or a minimum is tight | A manager, leaving the note | | Not approved | Something blocking is missing, or a minimum is breached | Automatic, and communicated | > [!IMPORTANT] > The middle level is what stops approval becoming an empty stamp. Without it, people approve what does not quite comply so as not to block the work, and from then on "approved" means nothing. ## The commonest design mistake Making everything desirable mandatory. It ends with half your suppliers marked not approved over things nobody cares about, and someone bypassing the process to get work done. Mandatory means what genuinely prevents contracting. > [!WARNING] > If approval expires — and it usually does, because insurance and certificates expire — the status has to recalculate itself. An approval reading "approved" with insurance that lapsed three months ago is worse than no approval at all. > [!NOTE] > Write the criteria down even if it is four lines. The value is not in the document: it is in two different people deciding the same thing. **Can criteria differ by supplier type?** Yes, and they should: you do not ask the same of someone entering site as of someone shipping material. **What about a supplier who fails a criterion but is essential?** That is what "approved with conditions" is for: it is decided expressly and who decided is recorded. **Do we tell the supplier why they are not approved?** It helps: most fix it once they know what is missing. ## Ejemplos **Two buyers at the same company approve suppliers by different standards.** - Write four criteria with their minimums - Add an "approved with conditions" level for exceptions → "Approved" comes to mean the same thing whoever decides, and exceptions carry a name and a reason. **Each department approves suppliers on different criteria and the same supplier passes in one and fails in another.** - Sets a common list and writes it down - Marks what is mandatory and what is desirable - Applies the same criteria to suppliers already working with you → Approval means the same across the company and stops depending on who does it. **A document nobody ever looks at is requested.** - Reviews what is actually used and drops the rest → The supplier delivers sooner because less is asked. **A critical supplier passes on the bare minimum.** - Matches the level of scrutiny to the risk → What is critical is examined more closely than what is incidental. **Approval happens once and nobody reviews three years later.** - Schedules the periodic review → The approval stays true. **The criteria live in one person's head.** - Writes them into the template → Approval outlives whoever set it up. --- --- id: KB-CF-010 url: https://app.codecontract.io/help/use-cases-by-capability/inheriting-a-system-somebody-else-built idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: avanzado actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-002, KB-TL-013] citadoPor: [KB-CF-020] --- # Inheriting what somebody else built _You take over a role and inherit processes, cases and criteria you never wrote._ **Responde a:** i inherited document management from someone else · taking over a colleague's processes · understanding a system i did not build · reviewing configuration someone else left Someone left and this is yours now. One temptation is to rebuild it your way; the other is to touch nothing out of fear. Both are expensive. What works is a short, ordered walkthrough before deciding what to change. ## The walkthrough, in one afternoon 1. **See what is alive** — How many cases moved last month. What has not moved in six months is probably unused. 2. **See who signs in** — The log shows who actually uses this. Sometimes it is two people, and not the ones you were told. 3. **Open the most-used processes** — Read them as the supplier who receives them. That is where you see why people deliver or not. 4. **Look for what expires** — It is what can blow up unannounced if nobody was watching. ## What to touch, in what order | Finding | Urgency | What to do | | --- | --- | --- | | Expired documents and nobody warned | High | Fix it this week | | Accounts and accesses of people who left | High | Close them | | Processes with titles nobody understands | Medium | Rewrite them; it lifts delivery and breaks nothing | | A folder structure you dislike | Low | Leave it. Changing it disorients people who had found their way | > [!IMPORTANT] > Do not close or delete cases you do not yet understand. One may be open for a reason you cannot see — a claim, a stalled site — and closing it with the wrong reason leaves a record you will have to explain later. > [!WARNING] > If whoever built it is still reachable, half an hour with them saves two weeks. What is written nowhere is why each thing was decided, and only they have it. > [!NOTE] > Change one thing at a time and let two weeks pass. If you change five and something worsens, you will not know which. **Can I see who configured each thing?** The log shows who made each change and when. **What if a process is clearly wrong?** Change it, but for future cases: running ones are corrected individually. **Is it worth rebuilding entirely?** Almost never. What works, however ugly, is worth more than something elegant and untested. ## Ejemplos **Someone inherits a company's document management when the manager leaves.** - Spends an afternoon on the walkthrough - Closes four accesses and fixes nine unwarned expiries - Leaves the folder structure alone → Within a week they have the urgent things under control without breaking anything people already knew how to use. **You inherit a process built by somebody who has left and nobody knows why it asks for what it asks.** - Goes through the list with whoever uses it today - Removes what nobody looks at and notes why the rest stays → The process is understood and can be improved rather than touched fearfully. **The inherited process has ten phases and nobody remembers the reason.** - Checks which phases genuinely add something → The process shortens without losing anything. **Something is changed and it breaks a case nobody knew about.** - Tests the change on a real case before applying it → The improvement does not break what worked. **There are four similar inherited templates.** - Unifies and archives the ones not being launched → The list becomes readable again. **Nobody knows which files use each template.** - Checks which ones are still active → You touch what is in use rather than what is dormant. --- --- id: KB-CF-011 url: https://app.codecontract.io/help/use-cases-by-capability/is-controlling-third-party-documentation-mandatory idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-008, KB-CF-009] citadoPor: [KB-LE-004] --- # Is controlling third-party documentation mandatory? _The short answer is "it depends", and what it depends on can be explained._ **Responde a:** is it mandatory to request supplier documentation · must i check my subcontractors documentation · what happens if i do not check a supplier · liability for an undocumented supplier · obligation to verify subcontractors The question nearly always arrives with a scare behind it: an inspection, a claim, or something someone read. The honest answer is that it depends on three things, and all three can be checked in five minutes. ## What it depends on | Factor | What to check | | --- | --- | | Your activity | In some sectors checking third parties is an express duty: construction, food, transport, among others | | The relationship | Someone working on your premises changes things compared with someone who only sells to you | | Your contracts | Many duties do not come from law: they come from what you signed with a large customer | > [!IMPORTANT] > This article is not legal advice and cannot tell you whether your case is covered. What it can tell you is where to look and what to ask: take these three questions to your adviser and you will come out of one meeting with an answer. ## What tends to happen even where it is not mandatory Even if no rule expressly obliges you, the problem arrives through another door: if a supplier of yours causes harm, the question of whether you checked anything comes up anyway. And answering "we did not check" is different from answering "we checked and this is what we held". **En corto** - Being able to show you asked, even if the other side never delivered. - Being able to say what that company held on the date of the work, not today. - That the check does not depend on somebody remembering. > [!WARNING] > The expensive part is usually not lacking the document: it is being unable to show you asked for it. A case shows the request with its date even if no answer ever came, and that changes the position entirely. > [!NOTE] > If your customer requires you to check your suppliers, that is already an obligation of yours by contract, whether or not it has a legal basis. It is usually how it arrives. **What if a supplier refuses to provide documents?** That is a commercial decision of yours. The case at least records that it was requested. **Is asking once enough?** Rarely: what evidences something usually expires, and what matters is the status on the date of the work. **Does this apply to small suppliers?** The duty rarely distinguishes by size; what can be adjusted is what you ask for. ## Ejemplos **A company receives a claim over damage caused by a subcontractor.** - Retrieves the case: documents were requested and some arrived - The record shows what that firm held on the date of the work → The position moves from "we did not check" to "this is what we held and this is what we asked for", which is a different conversation. **Third-party documentation is controlled because a client demands it and nobody knows what the rules require.** - Checks with the adviser what applies to your activity - Separates what the client demands from what the rules require → Effort is sized knowing where each requirement comes from. **Everything is requested just in case.** - Requests what answers a specific requirement → The supplier delivers sooner and the archive is usable. **Large suppliers are controlled and small ones are not.** - Matches the criteria to risk rather than size → The control covers where the exposure actually is. **A client asks how it is controlled and there is no written answer.** - Documents the criteria → The answer exists before the question. **Controls happen and nothing records that they did.** - Records the checks performed → The control moves from assertion to evidence. --- --- id: KB-CF-012 url: https://app.codecontract.io/help/use-cases-by-capability/the-annual-renewal-for-everyone-at-once idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-001, KB-CF-004] citadoPor: [KB-CO-017, KB-CC-015, KB-TL-023] --- # The annual renewal for everyone at once _Two hundred suppliers renewing in January. How to do it without losing the month._ **Responde a:** renewing documentation for all suppliers · annual documentation campaign · requesting certificates from everyone at once · bulk document renewal Many companies concentrate document renewal into one month: January, the start of the financial year, or the framework contract anniversary. It is a brutal spike of repetitive work that takes two afternoons done well, and eats the month done one by one. ## How to approach it 1. **Pull the list of what expires and when** — Before sending anything. What is already current is left alone. 2. **Group by what you are asking for** — Not everyone needs the same: a haulier and an accountancy firm do not share a list. 3. **Launch each group in one go** — One send per group, not one per supplier. 4. **And leave the chasing on automatic** — That is where the real work was: the reminders, not the first send. > [!IMPORTANT] > The step that saves money is the third: sending the same thing to two hundred counts as **one action**, not two hundred. Renewing one by one pays per send and spends the time as well. ## What to check before starting | Check | Why | | --- | --- | | That contacts are alive | Half the failures are addresses of people who left | | That the document list is current | Asking for last year's forces a second round | | That there is margin before expiry | Four weeks, not four days | | And who reviews what arrives | If undecided, it will pile up unreviewed | > [!WARNING] > The last is the forgotten one. Launching the campaign is easy; the hard part is someone looking at two hundred replies. If nobody has that slot in their diary, you will have the documents and still not know whether they are any good. ## What to do about non-responders **En corto** - After three reminders it stops being a chasing problem and becomes a decision. - That decision — block, escalate, accept the risk — is yours and is best written down. - And whoever fails to respond two years running is probably no longer a supplier. > [!NOTE] > Spreading renewal across the year by contract date rather than by calendar removes the spike entirely. It costs once and pays every year after. **Can I stagger it by groups?** Yes, and for very large lists it is better: the review is spread too. **What if someone replies with questions?** Answer in the same thread; it stays in their file rather than in a loose email. **How much does it consume?** One send per group plus reminders. The same work as doing a single one. ## Ejemplos **A company spends three weeks every January renewing supplier documentation.** - Groups by what is requested and launches four sends - Leaves reminders on automatic and shares out the review → Closes the campaign in two afternoons and the following year spreads it by contract date. **The annual renewal of two hundred suppliers happens in January, by hand and by email.** - Launches the same process to all at once - Excludes those who renewed another way - Checks progress per supplier rather than per inbox → The campaign is prepared in an afternoon and by February you know exactly who is missing. **It launches in August and a third reply.** - Picks the date against the sector's calendar → Response rates rise without changing anything else. **Everything is requested again even though half is still valid.** - Requests only what expires or has changed → The supplier delivers sooner because less is asked. **The campaign ends with thirty still outstanding.** - Sets an escalation or closing criterion → The campaign genuinely finishes. **The following year everything is rebuilt from scratch.** - Saves the campaign as a template → The second renewal costs a fraction. --- --- id: KB-CF-013 url: https://app.codecontract.io/help/use-cases-by-capability/is-this-worth-digitising idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-008, KB-CF-005] citadoPor: [KB-PS-014, KB-CF-019] --- # Is this worth digitising? _Four questions that tell you whether a given process gains anything, or is fine as it is._ **Responde a:** is it worth digitising a process · which processes to digitise first · when digitising is not needed · working out whether a change pays off Not everything done on paper or in a spreadsheet is wrong. Some processes work perfectly that way, and changing them only adds steps. These four questions separate the ones that gain from the ones that do not. ## The four questions 1. **Is someone outside involved?** — If the process only affects you, you gain little. As soon as a third party must supply or sign, everything changes. 2. **Will it have to be proven later?** — If someone can ask you for evidence that it happened, with a date, a spreadsheet will not do. 3. **Does it repeat often?** — Ten times a year does not pay. Ten times a week does. 4. **Does anything expire?** — What expires needs warnings, and that is where manual control always fails. > [!IMPORTANT] > **Two yeses** usually already pay. With all four, it is among the first to tackle. With none, leave it as it is and do not feel bad: changing what works costs real team time. ## Examples of both kinds | Process | Yeses | Verdict | | --- | --- | --- | | Supplier documentation | All four | Among the first | | Employment contracts and annexes | Three | Clearly worth it | | Office visitor log | One | Probably not | | Materials shopping list | None | Leave it alone | > [!WARNING] > Beware the temptation to digitise the easy thing first. The easy thing tends to be internal, which is exactly what gains least. What pays is what forces you to chase someone outside, however unappealing a starting point. ## What should not weigh on the decision **En corto** - "We've always done it this way" — an argument neither for nor against. - "Everyone else does" — their process may look nothing like yours. - And "while we're at it" — a process that gains nothing gains nothing by tagging along. > [!NOTE] > If unsure, try one and measure one thing: how often someone had to ask where it stood. If that number falls, the process gained; if not, you have your answer. **What if the team resists?** Start with the process that annoys them most, not the one that interests you most. **Can it be done halfway?** Yes: what goes outward, here; internal work, wherever it is. That is a legitimate coexistence. **How long before it shows?** In a process involving a third party, two weeks. ## Ejemplos **A company wants to digitise its internal machine incident log.** - Answers the four questions and gets only one yes - Digitises subcontractor documentation instead → Spends the effort where all four were yes and leaves the internal log alone. **Digitising a form filled in twice a year is proposed.** - Counts how often it is used and what it costs today - Compares that against building and maintaining it → Effort goes to what repeats rather than to what sounds modern. **A process is digitised and still ends up on paper.** - Checks where the circuit ends today → Digitisation reaches the end or does not happen. **The easy part is digitised and the painful part is left.** - Starts with what consumes most time → The saving shows from the first month. **It is digitised and nobody uses it because by hand was faster.** - Checks the new way is more convenient for whoever uses it → Adoption does not depend on nagging. **It is digitised by copying the paper circuit, dead steps included.** - Removes steps that existed only because of paper → The new process is shorter than the one it replaces. --- --- id: KB-CF-014 url: https://app.codecontract.io/help/use-cases-by-capability/the-file-for-a-machine idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-001, KB-IU-005] citadoPor: [KB-CN-012, KB-CN-014, KB-IU-016] --- # The file for a machine _One piece of equipment, a long service life, and everything you must be able to show about it._ **Responde a:** machine documentation · equipment maintenance history · machinery inspection certificates · industrial equipment file A machine, a vehicle, lifting gear or an installation share something with a person: they accumulate documentation over years, and that documentation is always requested by equipment, never by the date the paper arrived. ## What an equipment file contains | Block | What it includes | Expires | | --- | --- | --- | | Origin | Invoice, declaration of conformity, manual | No | | Certification | Mandatory inspections and examinations | Yes, and it weighs most | | Maintenance | Preventive, corrective, parts fitted | No, but it accumulates | | Use | Who is authorised to operate it and their training | Yes | > [!IMPORTANT] > The second and fourth blocks are what generate penalties: equipment without a current inspection, or operated by someone without evidenced training. The other two generate quieter losses, like being unable to claim under warranty. ## What makes it work 1. **One file per item, identified as on the shop floor** — With the same number or name people use, not a new code. 2. **Everything done to it, inside** — Including third-party interventions, which are the ones that get lost. 3. **Due dates with warnings and an owner** — Each mandatory inspection with its date and who arranges it. 4. **And a live list of authorised operators** — With their training; if someone falls out of date, they stop being authorised. > [!WARNING] > The commonest mistake is filing by maintenance contractor instead of by equipment. It works while the contractor stays the same; the day it changes, the machine's history is split in two and neither half tells the whole story. ## What it is for besides compliance **En corto** - Deciding repair versus replacement, with accumulated cost in front of you. - Claiming under warranty knowing what was fitted and when. - Selling the equipment with its history, which is worth money. - And answering an insurer after an accident. > [!NOTE] > The same scheme suits fleet vehicles, medical equipment, refrigeration plant and pressure equipment. Which inspections are mandatory changes; that the file belongs to the equipment and follows it for life does not. **What if the equipment moves site?** The file travels with it; it belongs to the equipment, not the site. **Should old history be loaded in?** Whatever exists and is relevant. From today, everything. **Does it suit hired machinery?** Yes, and it is advisable: you will be asked for its documentation even though it is not yours. ## Ejemplos **A plant files maintenance by contractor and then changes maintenance company.** - Reorganises by equipment, using the identifier people actually use - Links due dates and authorised operators → Each machine's history stays whole and inspections stop lapsing unnoticed. **A machine has been on the plant floor for fifteen years and its documentation sits in three drawers and an email.** - Gathers manual, certificates and inspections into one file - Records the inspections due by calendar - Notes which components have been replaced and when → Faced with a breakdown or an inspection, the machine's history reads in one place. **A unit still under warranty is repaired.** - Records which warranties are live → The avoidable cost is avoided. **A component is replaced and the documentation still describes the old one.** - Updates the file with every change → The paper describes what is installed. **The machine is sold and its documentation stays behind.** - Hands over the file with the machine → The buyer receives what covers it. **Inspections are remembered from memory.** - Records each due date with a warning → The calendar stops depending on remembering. --- --- id: KB-CF-015 url: https://app.codecontract.io/help/use-cases-by-capability/offboarding-a-supplier idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-006, KB-TZ-013, KB-CF-016] citadoPor: [KB-CF-020] --- # Offboarding a supplier _Onboarding gets documented in detail and offboarding barely at all, which is where the loose ends are._ **Responde a:** ending work with a supplier · supplier offboarding documentation · what to do when a supply contract ends · closing a supplier relationship Onboarding a supplier means asking for everything. When you stop working with them, usually nothing happens: you just stop calling. And that leaves open ends that surface months later, almost always at the worst moment. ## What to close 1. **Any access they held** — If they entered your systems or premises, withdraw it the same day. 2. **What was left half-done** — Open orders, live warranties, consigned stock, borrowed tools. 3. **The documentation you must keep** — It is not deleted on offboarding: obligations run their own periods. 4. **And the reason, in one written line** — Price, quality, they closed down. It stops you re-hiring them by mistake in three years. > [!IMPORTANT] > The fourth looks like bureaucracy and is the opposite. Without it, two years on someone re-approves the very supplier there was a serious problem with, because whoever knew has left and the file only shows they stopped being used. ## What not to do | Temptation | Why not | | --- | --- | | Delete their file | Obligations and possible claims remain | | Leave them active "in case they come back" | They appear in lists and alerts, polluting counts | | Say nothing to the team | Someone will keep asking them for things for months | > [!WARNING] > The second is commonest. A supplier neither active nor closed keeps receiving automatic documentation renewal requests, which is awkward for them and consumes on your side for no purpose. ## If the exit is contentious **En corto** - Withdraw access first and talk afterwards. - Record the state of what is outstanding before closing anything. - And keep the full history: it is what supports any later claim. The history includes what went well, not only what went badly. A claim stands up better when you can show the whole year and not just the last month. > [!NOTE] > The same scheme suits offboarding a client, an external collaborator or a subcontractor. What must be returned changes; that the exit is documented like the entry does not. **How long must their file be kept?** Whatever the applicable obligations and claim periods require, with margin. **What if they work with us again?** Reactivate with current documentation; the earlier history stays and is useful. **Must it be communicated formally?** It depends on the contract: where notice is agreed, that communication has a form and a deadline. ## Ejemplos **A company stops using a supplier and two years later re-approves them.** - Writes the reason for offboarding in their file - Closes access and outstanding items the same day → The next approval happens knowing what occurred, instead of repeating the problem. **You stop working with a supplier and their file stays open and active.** - Closes the file, stating the reason - Revokes their access and stops the reminders - Retains the history per the retention policy → The active supplier list becomes true again and the history still exists. **The supplier is deleted and the history of what they supplied vanishes.** - Archives rather than deletes → What happened stays consultable. **They keep receiving reminders months later.** - Stops the open processes on closing → Nobody receives requests from an ended relationship. **Work resumes with them the following year.** - Reopens the file with its history → Nothing already provided is lost. **Nobody knows which suppliers are genuinely active.** - Periodically reviews those with no activity for a while → The list reflects who you actually work with. --- --- id: KB-CF-016 url: https://app.codecontract.io/help/use-cases-by-capability/onboarding-a-new-client idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-006, KB-LE-009] citadoPor: [KB-CF-015] --- # Onboarding a new client _Supplier onboarding is documented in detail and the onboarding of whoever pays you barely at all._ **Responde a:** new client onboarding documentation · what to ask a client before starting · client billing details and contract · starting work without a signed contract With a new supplier you ask for everything. With a new client you start working, because there is a rush and because asking for paperwork from whoever will pay you feels awkward. And almost every payment and scope problem of the following months is born right there. ## The minimum before starting | What | What it is for | What happens if missing | | --- | --- | --- | | Who they are and who signs | Knowing which entity you deal with and who binds it | You invoice one company and another asked for the work | | What was agreed | Scope, price and deadlines | It gets argued on the first invoice | | Billing details and payment method | Getting paid without friction | The invoice comes back and the clock restarts | | Who to talk to about what | Operations, incidents, payments | Everything goes through one person who is sometimes away | > [!IMPORTANT] > The first costs the most money and gets the least attention. Working for "the group" and invoicing whichever entity you are told at the end is a source of awkward non-payments: if the company that asked for the work is not the one receiving the invoice, getting paid stops being a formality and becomes a negotiation. ## How to do it without seeming distrustful 1. **Make it the normal step, not an exception** — "I'll send the onboarding and we start as soon as it is signed" is a sentence nobody argues with. 2. **Ask for little, all at once** — Four things in one request get answered; seven separate emails do not. 3. **And sign the scope even if it is brief** — Half a signed page is worth more than ten unsigned pages of proposal. > [!WARNING] > The case to decide before it happens: **starting with no contract because the client is in a hurry**. It always happens and is sometimes the right call, but it should be somebody's decision and be recorded — what you start with, until when, and what happens if the signature never comes. Without that, three months on nobody will remember what was agreed or who said it was fine to start. ## What to keep about the relationship from day one **En corto** - The signed scope and its later amendments. - The special terms you granted, even if agreed by email. - Contacts by function, not just the buyer. - And incidents, which will be the basis of the renewal. The second is the most often lost: a discount or a special deadline agreed in an email two years ago is still in force for the client and recorded nowhere for you. > [!NOTE] > If your sector requires additional checks before accepting a client — identification, sector-specific verifications — that step comes before starting work, not after. **Confirm which checks apply to you with your adviser**; this describes the commercial and documentary part common to any onboarding. **What if the client will not sign anything?** That is useful information about how the relationship will go. At least record what was agreed, in writing. **Is an email confirmation enough?** As an agreement it helps; for anything significant, a signature that evidences who accepted is better. **Is this needed with a small client?** Fewer papers, same criterion: who they are, what was agreed and who gets invoiced. ## Ejemplos **A company starts work for a group and on invoicing finds the signing entity is a different one.** - Makes client onboarding the normal first step, with who signs and who is invoiced → Payments stop being argued and the agreed scope is on record from day one. **A new client signs and their documentation is requested once work has already started.** - Launches onboarding on signature, not on starting work - Requests first what conditions being able to invoice - Records the checks performed on accepting them → The engagement starts complete and the decision to accept is documented. **Each person asks for different things at onboarding.** - Uses one onboarding template → Files are comparable between clients. **An onboarding document expires and nobody reviews it.** - Records validity on receipt → The file stays true. **An old client never went through the current onboarding.** - Checks what is missing in the older files → The gap closes without waiting for a review. **There is no record of what was checked before accepting the client.** - Records the checks performed → The decision to accept is explicable. --- --- id: KB-CF-017 url: https://app.codecontract.io/help/use-cases-by-capability/keeping-track-of-team-training idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-001, KB-CR-016, KB-CF-019] citadoPor: [KB-CS-040] --- # Keeping track of team training _What expires here is not a company document: it is a person's authorisation to do their job._ **Responde a:** employee training control · training matrix and expiries · evidencing someone is trained · team licences and certifications Expiry control usually gets built for supplier documents. And then it turns out that what is most often asked for in an inspection or after an incident is not a company's insurance: it is whether that specific person was authorised for what they were doing that day. ## Why it is controlled worse than everything else | Supplier document | A person's training | | --- | --- | | One per company | One per person and per subject | | Expires on a clear date | Depends on when each person did it | | Requested by whoever runs purchasing | Requested by nobody until it is needed | | If missing, you chase it | If missing, that person should not be doing that | > [!IMPORTANT] > The last row is the real difference. Expired insurance is solved by asking for it; expired training **is not solved with a phone call**: they must be trained again, and until then that person should not be in that role. So here the warning margin is not a convenience — it must be enough to arrange a course, not to send an email. ## What to hold per person 1. **What their role requires, written down** — Unwritten, each manager demands what they believe and nobody can verify anything. 2. **What they hold and since when** — With the certificate, not a note saying they did it. 3. **When it expires and who arranges renewal** — By name: "HR" does not book courses, a person does. 4. **And what happens meanwhile** — It is the uncomfortable decision, and better taken calmly. > [!WARNING] > The case that wrong-foots people is someone changing role inside the company. Nobody onboards or offboards them: they are the same employee, with the same training they had — which was for their previous role. **An internal move triggers no review, and it is exactly when someone starts doing something they are not trained for**, in complete good faith on both sides. ## What you must be able to show **En corto** - That they were trained before starting that task, not after. - The certificate, not the course invoice. - And that whoever delivered it was entitled to, where the subject requires it. The first is always checked and fails by weeks: the course happened, the certificate arrived later, and in between there was work. The date that counts is the training date, which is why it is worth recording when it took place, not only when the paper arrived. > [!NOTE] > The same applies to licences, authorisations and internal permits: driving a forklift, handling food, working at height, entering a restricted area. The mechanics are identical; who demands it changes. **What about training delivered in-house?** It counts the same, and is recorded the same: who delivered it, to whom and when. **Can the employee supply their own certificate?** Yes, by their link, and it arrives sooner and lands in their file. **Must it be kept after they leave?** For the applicable period: it evidences what they did while they were there. ## Ejemplos **An operator moves to a different role internally and starts using new machinery.** - The role change triggers a review of what the new role requires → A missing authorisation is spotted before they use it, rather than after an incident. **A technician is stopped at a client's gate because their training lapsed a month ago.** - Records each person's training with its validity - Warns with the lead time the renewal needs - Checks per person before assigning them to a job → Renewal happens before it hits the rota, not at the client's gate. **Somebody new joins and starts without the training done.** - Checks what is missing before assigning them work → Onboarding is resolved before the first job. **A client asks you to evidence the training of the team coming in.** - Checks each person's file → The handover is prepared in minutes. **Training happens and the certificate stays on paper.** - Captures it and attaches it to the person → The paper stops being the only copy. **All the training expires in the same month.** - Warns far enough ahead to spread it out → The calendar spreads out. --- --- id: KB-CF-018 url: https://app.codecontract.io/help/use-cases-by-capability/keeping-track-of-everyone-s-insurance idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-002, KB-CF-009] citadoPor: [KB-NO-028] --- # Keeping track of everyone's insurance _Yours, your suppliers' and those of anyone coming to work. Plus a detail almost nobody checks._ **Responde a:** tracking suppliers insurance · certificate of current insurance · how to know the policy is still paid · third party liability insurance Almost every company ends up tracking policies that are not its own: the supplier coming on site, the haulier, the technician going up on the roof. You ask for a certificate, file it, and it feels solved. That feeling is slightly misleading. ## What each document proves | Document | What it proves | What it does not prove | | --- | --- | --- | | The policy | What it covers and up to what limits | That it is still alive today | | The insurance certificate | That it existed and what it covered when issued | That the current period has been paid | | The premium receipt | That this period is paid | What exactly is covered | | The particular conditions | The exclusions, where the detail lives | Nothing about validity | > [!IMPORTANT] > There is the detail almost nobody checks: **an insurance certificate states what was true the day it was issued**. A policy can be cancelled for non-payment the following month and the certificate you filed still looks just as impeccable. That is why, in the cases that really matter, what you ask for is not only the certificate: it is proof for the current period. It is the difference between holding a paper and being covered. ## What is worth looking at, and it is not the date **En corto** - Which activity it covers: a policy may not cover the exact work they do for you. - The per-claim limits, not just the annual aggregate. - The exclusions, which are usually where the problem comes from. - And if you must appear as an additional insured, that it actually says so. 1. **One file per company or person, not per site** — The policy is one; the places it is needed are many. 2. **With the renewal date warning early** — Policies all renew in the same month and swamp the review. 3. **Request the renewal before expiry, not after** — A day without documented cover is a day someone will look at. 4. **And keep which version was in force when** — If something happens, the question will be about that day's. > [!WARNING] > A case that always turns up and throws people: **the policy is in force but does not cover what matters to you**. It covers the supplier's main activity and not the specific work done at your premises, or it carries a limit well below what your contract requires. The document is fine, the dates are fine, and you are still exposed — which is why the paper gets read, not just filed. > [!NOTE] > Which covers and limits are worth requiring from each type of supplier, and what obligations you carry, depend on your activity and your contracts. **Your broker or adviser decides that**; the point here is that the control does not stop at checking a date. **Should I ask every supplier for the receipt?** Those posing a real risk. For the rest the certificate is enough. **How often should it be reviewed?** At renewal, and always before important work. **What if the supplier refuses to hand over the policy?** The certificate usually suffices; the full policy is their information. ## Ejemplos **A company files its suppliers' insurance certificates and considers the control done.** - Asks the higher-risk ones for current-period proof and reads the exclusions → It finds one policy cancelled for non-payment and another not covering the contracted work. **A company with forty partners discovers that two worked six months with a lapsed policy.** - Records each policy's validity on receipt - Warns far enough ahead to renew - Checks the status before assigning work → Nobody works uncovered and the gap closes before anyone asks about it. **The policy is sent without checking what it covers.** - Checks it covers that work before accepting it → The gap does not surface on the day of a claim. **The client asks for a limit above what is contracted.** - Discusses it with the broker before signing the contract → The commitment matches the real cover. **The policy expires midway through a long job.** - Records the expiry when filing it → Renewal happens before it bites. **Last year's is sent out of habit.** - Checks validity before sending → The client receives the current one. --- --- id: KB-CF-019 url: https://app.codecontract.io/help/use-cases-by-capability/replacing-a-paper-form idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-013, KB-DI-012] citadoPor: [KB-CF-017] --- # Replacing a paper form _The job sheet, the checklist, the goods-in form. Digitising them is easy; the hard part is keeping what they did well._ **Responde a:** moving a job sheet to digital · replacing paper checklists · digital form for field staff · digitising goods-in forms Almost every company has three or four pieces of paper unchanged for years: the sheet the technician fills in, the goods-in checklist, the form the client signs on delivery. They work, which is why nobody touches them — until one from eight months ago has to be found. ## What you gain and what needs care | Aspect | On paper | Once digital | | --- | --- | --- | | Filling it in | Fast, anyone can | Must be just as fast or it goes unused | | Finding it later | Depends on the folder and on luck | This is where nearly all the gain is | | Knowing something is missing | Visible if someone looks | Can be required before closing | | Who filled it and when | Handwriting and a date written by hand | Recorded without anyone writing it | | The signature of whoever takes something on | Explicit, which is why it is there | Has to be preserved deliberately | > [!IMPORTANT] > The last row is what most often gets lost along the way: **if the paper had a signature line, it was almost always because someone was taking something on**. The client accepts the delivery, the technician answers for the inspection, the supervisor authorises the dispatch. Digitising, it is easy to keep the fields — the visible part — and drop the signature, which was what made that paper evidence. A form nobody has accepted is an internal record, not a document you can hold a third party to. ## How to make the switch without it being abandoned 1. **Copy the paper exactly for the first version** — Improving and digitising at once is what makes nobody use it. 2. **Drop the fields nobody filled in** — A real paper shows what is surplus: look at the blanks. 3. **Test it where it gets filled in, not in the office** — Outdoors, with gloves, poor signal and in a hurry. 4. **And run alongside paper for a few weeks** — Withdrawing paper on day one guarantees its return. > [!WARNING] > What decides survival is not the design: **it is how long it takes whoever fills it in, compared to paper**. If paper took thirty seconds and the digital version takes two minutes, they will go back to paper however much it costs you later. Five fields filled standing up beat fifteen perfect ones every time. And whatever does not fit in those five is solved with a photo: a photo is always faster than typing. ## What to settle before starting **En corto** - Who fills it in and under what real conditions. - What is needed to close it, and what is optional. - Where it ends up filed and what it links to: client, file, equipment. - And if someone outside has to accept it, how they will. > [!NOTE] > If the paper was imposed by a client or a standard, check which format they accept before changing it. **Ask whoever requires it, or your adviser**; anything purely internal can be redesigned freely. **What if the team resists?** It nearly always takes longer. Time it with them watching. **Should old papers be kept?** Yes, for as long as they must be. The new form does not change what is signed. **Can we start with just one?** It is the only way that works. Pick the one you most often go looking for. ## Ejemplos **A company digitises its job sheet and leaves out the client's acceptance.** - Brings the signature back into the sheet, at the moment of delivery → The sheet works as evidence towards the client again, not only as an internal record. **A paper job sheet is filled in on site, gets wet and reaches the office three days later.** - Replaces paper with capture at the workface - Collects the same fields the form had - Lets it reach the file when the job finishes → The sheet arrives legible the same day and invoicing does not wait for it to turn up. **The form is digitised by copying its twenty fields.** - Reviews which ones are actually used → The new form is shorter than the paper one. **The digital form is filled in at night from memory.** - Makes it capturable at the moment, from a phone → The data is exact rather than reconstructed. **It is digitised and paper keeps circulating in parallel.** - Sets the date from which only digital counts → There stop being two circuits. **A mandatory field is missing and nobody spots it until close-out.** - Marks the fields that cannot be left empty → The sheet arrives complete. --- --- id: KB-CF-020 url: https://app.codecontract.io/help/use-cases-by-capability/when-someone-leaves-the-team idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-007, KB-CF-015, KB-CF-010] citadoPor: [KB-CF-005] --- # When someone leaves the team _Access is cut in a minute. What that person was carrying takes three weeks to surface, and surfaces badly._ **Responde a:** an employee handling documentation is leaving · handover when someone leaves · what to do with the requests of someone leaving · deactivating a user and their files Two weeks' notice, the send-off, access cut… and three weeks later a client asks about something only that person was carrying. This is not an HR problem: it is that someone's documentary work lives spread across open requests, contacts who only ever answered them, and folders nobody else looked at. ## What is left orphaned | What | Where it shows | When it blows up | | --- | --- | --- | | Open requests in their name | Nobody chases them | The day the document is needed | | Contacts who only spoke to them | They stop replying | At the next renewal | | Documents only in their inbox | They are in no file at all | At the first audit | | Their training and authorisations | They counted towards your matrix | When the matrix is requested | > [!IMPORTANT] > The order matters more than the list: **hand over first, cut access after, on the same day**. Cutting on Friday and handing over «when there's time» is the mistake that turns an orderly departure into three months of archaeology, because once the account closes you can no longer ask «where was this?» of the only person who knew. Postponing the cut is not the answer either: move the handover date forward, not the closing date back. ## The handover, in four moves 1. **Reassign everything open before the last day** — Each live request goes to someone staying, with a name and a face. 2. **Introduce whoever stays to the contacts that were theirs** — A two-line email saves three months of silence. 3. **Move into the file whatever only exists in their inbox** — What is not in the file does not exist when someone asks. 4. **And close access the same day they leave** — Not before, as it blocks the handover; not after, as it then never happens. > [!WARNING] > There is a half-measure that looks practical and is the worst of both: **leaving their mailbox alive and forwarding it**. Contacts keep writing to someone who is gone, whoever gets the copy does not feel responsible for replying, and the record of who did what becomes unreadable. If something must outlive the person, let it outlive them under a function name —purchasing, quality— and not under the name of someone who left. ## What makes the next departure painless **En corto** - Every request has a live owner, not a historical name. - Important contacts know at least two people on your side. - Whatever arrives by email lands in the file the same day. - And deactivate rather than delete: it preserves who did what, which is exactly what gets asked later. > [!NOTE] > What may be kept from the activity of someone who leaves, for how long, and what to do with anything personal left in their account follows its own rules. **Your adviser settles that**; here we deal with the other half: not leaving the work ownerless. **What if they have already gone with no handover?** Do it anyway, in order: start with whatever expires soonest. **Delete their user or deactivate it?** Deactivate. Deleting takes the record of who did what with it. **Do contacts need telling?** Those who depended on that person, yes, and before the next request. ## Ejemplos **The person handling supplier documentation leaves and three renewals are left with nobody chasing them.** - Reassigns the open requests and introduces the replacement before the last day → The renewals carry on and suppliers reply to the right person, with no restart. **Somebody leaves the team with eleven open files in their name and thirty suppliers awaiting their reply.** - Reassigns their files before their last day - Changes the recipient on the outstanding notices - Stores what matters from their inbox in the files → No supplier is left waiting on an address nobody reads any more. **Their access stays active weeks later.** - Revokes access on their last day → The account reflects who works here. **Their account is deleted and their actions vanish from the history.** - Deactivates rather than deletes → The record of what they did is kept. **Nobody knows what was outstanding in their area.** - Checks what was waiting on their action → The handover starts with a list. **The knowledge was in their head and nowhere else.** - Records decisions in the files before the departure → The context outlives the person. --- --- id: KB-CF-001 url: https://app.codecontract.io/help/use-cases-by-capability/tracking-expiry-dates idioma: en categoria: casos-por-funcionalidad audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CR-001, KB-CS-001, KB-TL-004] citadoPor: [KB-CF-012, KB-CF-014, KB-TZ-014, KB-CF-017, KB-CR-007, KB-CS-004] --- # Tracking what expires _The capability that prevents the most trouble: knowing what expires before it does._ **Responde a:** track documents that expire · certificate expiry alerts · how to know which paperwork is about to expire · renew supplier documentation automatically · expiry alerts for insurance and training Almost every audit finding about documentation is not a missing document: it is one that was there and expired. The file looks complete, nobody checks the dates, and the problem shows up the day somebody checks them for you. **En corto** - Each document can carry its own expiry date. - The alert fires before it lapses, with whatever margin you choose. - Only what expires is re-requested, not the whole file. - An expired document is flagged, so a complete file does not mislead. ## What actually expires | Document | Typical validity | What happens if it lapses | | --- | --- | --- | | Tax clearance certificate | Months | Joint liability when paying that supplier | | Liability insurance | One year | An incident with no cover and nobody to answer for it | | Safety training | Varies by type | The worker should not be allowed on site | | Standard certification | One year | A direct finding in your client's audit | | Medical clearance | One year | Non-compliance at a labour inspection | ## How to set it up 1. **Mark which documents carry an expiry** — Not all of them: an ID document or company deeds do not need this and only add noise. 2. **Decide the warning margin** — Enough time to obtain the new one. For a certificate that takes two weeks to issue, warning three days ahead is useless. 3. **Let the renewal be requested automatically** — When the alert fires, the request for that specific document is re-sent. No need to redo the whole onboarding. > [!WARNING] > The most expensive mistake is setting the margin too tight. It has to cover how long the third party takes to obtain the document, not how long you take to ask for it. ## Frequently asked questions **Does the date have to be typed in by hand?** It can be requested as data, and on many documents automatic reading takes it from the certificate itself, which is more reliable than typing it. **Who receives the alert?** Whoever you choose on your team. The renewal request does go to the third party. **What happens to the expired document?** It stays in the history with its date. That is correct: it shows what was valid at each moment. **Can I see everything expiring this month at a glance?** Yes, by filtering on expiry. It is the view worth checking once a week. ## Ejemplos **A company discovers in an audit that four critical suppliers had certificates that expired months earlier.** - Marks expiry on the certificates of every critical supplier - Sets the alert at 45 days, which is how long they take to obtain - Lets the renewal be requested automatically → The following year the audit finds none expired, and nobody had to keep a calendar. **A company with sixty suppliers discovers at an inspection that three insurance policies lapsed months ago.** - Records the validity date when approving each document - Lets the warning go out with the lead time the renewal needs - Checks weekly what expires in the next thirty days → Expiries stop being discovered during a visit and start being resolved with weeks to spare. **The warning fires with two days to go and renewal takes two weeks.** - Adjusts the lead time to the real duration of the process - Adds the time the third party takes to reply → The warning arrives while action is still possible. **Warnings fall in August and nobody reads them.** - Brings forward those expiring in holiday periods → Renewals happen before nobody is around. **The warning goes to somebody who has left.** - Reviews who the warnings are addressed to → The warning reaches somebody who can act. **The document is renewed and the warning stays red.** - Checks the recorded date of the new document → The warning clears because the figure matches the paper. --- --- id: KB-CF-002 url: https://app.codecontract.io/help/use-cases-by-capability/keeping-track-of-expiry-dates idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-DI-005] citadoPor: [KB-CF-010, KB-CS-010, KB-CS-023, KB-CF-018, KB-CF-007, KB-CS-006] --- # Tracking expiry dates without remembering them _Have the system warn you before things expire, instead of finding out during an inspection._ **Responde a:** track certificate expiry · alert before an insurance policy expires · automatically renew supplier documentation · expired document alerts Documents that prove something almost all expire: insurance, tax clearance certificates, training, vehicle inspections, approvals. And on the day they expire nothing visible happens — the problem surfaces months later, when someone asks for the paper and it is out of date. **En corto** - The expiry date is read from the document itself when it carries one. - The warning arrives with enough margin to renew, not the day after. - Renewal can be requested from the third party without writing anything by hand. ## How to set it up 1. **Mark which documents expire** — On each document type, say it has an expiry. The ones that do not, none. 2. **Let it read the date** — Most certificates carry it in writing and it is extracted automatically. Those that do not are set by hand once. 3. **Choose the margin** — Thirty days is usually reasonable: time to ask and for the other side to send it. 4. **Let renewal request itself** — When the warning fires, the request goes to the third party using the usual process. ## Margins that work | Document | Warn at | Why | | --- | --- | --- | | Public liability insurance | 45 days | Renewal depends on an insurer, not on them | | Tax clearance certificate | 15 days | Issued on the spot, no more needed | | Mandatory training | 60 days | A course has to be arranged | | Approvals and audits | 90 days | Depends on a third party with a diary | > [!IMPORTANT] > A warning is useless if it reaches someone who cannot act. Put it in the name of whoever has the supplier's phone number, not a general inbox. > [!WARNING] > An expired document does not disappear: it stays, marked as expired. That is correct — it still proves what it proved at the time. **What if the supplier sends a new one early?** It replaces the previous one and the countdown restarts automatically. **Can I see everything expiring this quarter?** Yes, by filtering on expiry date. **Does an expiry block anything?** If you marked it mandatory, the case goes back to incomplete. ## Ejemplos **A company with 80 subcontractors discovers during an inspection that 14 have lapsed insurance.** - Marks insurance as an expiring document - Sets a 45-day warning to the purchasing lead - Lets renewal request itself → The following quarter there are zero lapsed policies and nobody had to keep count. **One person tracks a hundred and twenty documents' expiries in a spreadsheet and reviews them by hand every Monday.** - Records validity when each document is received - Lets the warning go out on its own with the set lead time - Keeps Monday for acting on what was flagged, not for hunting it → Monday goes from two hours of review to ten minutes of action. **Somebody leaves the company and expiry control leaves with them.** - Configures warnings against a role, not a person → The departure does not orphan the calendar. **Everything triggers a warning and the team stops reading them.** - Warns only about what requires action → The warning works again. **Two people review the same thing just in case.** - Makes clear who answers for each type → The work stops being duplicated. **The document is renewed and nobody clears the warning.** - Records the new document with its date → The status reflects reality without intervention. --- --- id: KB-CF-003 url: https://app.codecontract.io/help/use-cases-by-capability/getting-ready-for-an-audit idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-009, KB-TZ-002] citadoPor: [KB-TZ-007, KB-IC-001, KB-IC-002, KB-IC-003, KB-IC-004, KB-GL-014, KB-CS-007] --- # Getting ready for an audit _So the week before is not a scramble for paperwork._ **Responde a:** prepare documentation for an audit · an inspection is coming what do i need · give the auditor the files · iso audit documentation An audit does not check that you have the documents: it checks that you can prove when you had them. That difference is what turns the week before into a scramble or an afternoon. **En corto** - What is asked for is dates, not only content. - A link to the auditor avoids emailing forty files. - Better you find the gaps than the auditor does. ## Three weeks before 1. **Filter for whatever is incomplete or expired and close it.** 2. **Check the dates are where they should be: a document without a trusted date does not prove when it arrived.** 3. **Gather the specific scope they will look at, not everything.** ## On the day Give read access or a scoped link instead of sending files. The auditor looks at what they need, what they consulted is logged, and no copy of your contracts is left sitting in anyone's inbox. | What an auditor asks for | Where it is | | --- | --- | | The document | The case | | When it was received | The delivery date, which you did not set | | Who approved it | The approval record | | That it has not changed since | Public verification of the seal | > [!NOTE] > What impresses an auditor is not having everything: it is being able to show it on the spot without searching. That alone says how you work. > [!WARNING] > Do not hand-build a folder of what you will show. If you made the selection, the auditor knows it and will ask for the rest. **Can I give access to only part of it?** Yes, scoped to what falls within the audit. **Is what they looked at recorded?** Yes, with date and time. **What if something is missing?** Better that you spot it and explain the plan than discover it at the table. ## Ejemplos **A food business is given a month's notice of an audit.** - Filters and closes the nine incomplete cases - Prepares scoped access limited to the audited scope → The audit takes one morning and the report raises no documentation non-conformities. **A client announces an audit in three weeks and the documentation sits in four places.** - Asks the auditor for the exact list before starting - Launches on day one whatever depends on third parties - Checks each morning what is still outstanding → You reach the audit with what was asked for locatable, and tidy the rest later without pressure. **Everything is prepared and the auditor asks for something nobody anticipated.** - Checks the scope with whoever will audit before starting → The scope is set by whoever will review it. **A folder with everything is handed over just in case.** - Hands over only what matches each point → No unnecessary information is provided. **Once the audit passes, everything returns to the previous mess.** - Keeps the file current through the year → The next audit costs a fraction. **There is no record of what was given to the auditor.** - Records the bundle handed over, with its date → The handover is demonstrable afterwards. --- --- id: KB-CF-004 url: https://app.codecontract.io/help/use-cases-by-capability/sending-the-same-thing-to-many-people idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-001, KB-TL-005] citadoPor: [KB-TL-013, KB-CS-013, KB-CS-014, KB-CF-012, KB-CR-009] --- # Sending the same thing to many people _Forty amendments or three hundred requests without doing them one by one._ **Responde a:** send a document to many people at once · bulk contract signing · send the same amendment to all staff · batch sending An amendment for the whole workforce, the annual documentation request to two hundred suppliers, renewing an agreement with every client. It is the same problem three times, and it is solved the same way: one list, one document, one send. **En corto** - Each person receives their own version with their own details, not a generic email. - You track the batch, not three hundred separate sends. - A failure on one recipient does not stop the rest. ## How it works 1. **Prepare the list** — With names and a way to reach them. It comes out of your own system as is, without editing. 2. **Choose the document** — One only, with gaps filled from each person's details. 3. **Send and watch** — Tracking shows how many opened, how many signed and who has not. > [!WARNING] > Check the list before sending. Three hundred sends with the name field wrong is three hundred awkward conversations, and they cannot be pulled back out of anyone's inbox. ## Worth checking first - No duplicate addresses: the same person would get two. - Nobody who has already left. - Enough balance for the whole batch. - That the wording makes sense to someone with no context — by testing on one person first. > [!NOTE] > Sending to five trusted people first and waiting a day catches nearly every glaring error. It costs a day and saves redoing three hundred. **Can I stop halfway?** Yes. What has gone continues; the rest does not go out. **What if someone has no email?** They are sent by SMS or WhatsApp within the same batch. **Can I repeat with only the ones missing?** Yes, by filtering on those who have not responded. ## Ejemplos **HR sends the collective agreement amendment to 340 employees.** - Exports the list from their payroll system - Tests on five people on Monday - Sends all 340 on Tuesday → By Friday 310 are signed and there is a concrete list of 30 to phone. **The same annex must go to two hundred suppliers and it is done in manual batches of twenty.** - Prepares the list and launches the send at once - Excludes those who already have it signed - Checks progress per recipient rather than per inbox → The campaign is prepared in an afternoon and follow-up is one screen. **It goes to everyone and a hundred identical questions come back.** - Includes the context and the date in the notice itself → Query volume drops from the first send. **The list holds old addresses and a third bounces.** - Cleans the contacts before launching → The campaign does not start on bounces. **It launches in August and twenty per cent reply.** - Picks the date against the sector's calendar → Response rates rise without changing anything else. **Nobody knows who to chase after a week.** - Checks who is still outstanding → Those missing are chased rather than all two hundred. --- --- id: KB-CF-005 url: https://app.codecontract.io/help/use-cases-by-capability/how-to-stop-chasing-people idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-008, KB-CR-007, KB-CF-020] citadoPor: [KB-TL-012, KB-TD-003, KB-CL-002, KB-CF-013, KB-TD-016, KB-CC-009, KB-CF-006] --- # How to stop chasing people _What makes a third party deliver without you phoning three times._ **Responde a:** how do i get people to send documentation · suppliers do not respond · automate follow-up on requests · stop sending reminder emails Chasing is expensive and does not scale: each person chased is two emails, a phone call, and remembering again next week. What works is not chasing better, it is asking better. **En corto** - Asking for little and clearly delivers more than asking for everything well explained. - The system can do the nagging; the difficult conversation, it cannot. - If three people fail on the same item, the problem is the request. ## The four things that most raise delivery | Change | Effect | | --- | --- | | Split the request into small blocks | The largest, by some distance | | Write the document's full name | People stop delivering the wrong thing | | Show a visible deadline | Gives a reason to do it today | | Automatic reminders at 3, 7 and 12 days | Closes most of them with no effort from you | ## What automation does not fix If someone is not delivering because they disagree, because they do not have the document, or because the right contact is someone else, no reminder will solve it. That needs a phone call — but it will be one call, not ten. > [!IMPORTANT] > When a third party has gone a month without delivering and has opened every notice, stop reminding and phone them. Continuing in writing only gets you filtered. > [!NOTE] > The reasonable target is not 100% automatic: it is that 85% closes itself and you spend your time on the 15% that needs a person. **How much does splitting the request raise delivery?** It varies, but it is the highest-impact change of the four. **Are automatic reminders annoying?** Three well spaced, no. Six in a row, yes, and you end up in spam. **Can I stop chasing entirely?** No, and you should not want to: some conversations are worth having precisely because a person has them. ## Ejemplos **A manager spends six hours a week chasing documentation.** - Splits requests into three blocks - Renames documents with their official titles - Turns on reminders at 3, 7 and 12 days → Drops to one hour a week, spent phoning the four cases that genuinely need it. **One person spends an hour every morning emailing the suppliers who are missing.** - Configures the automatic reminder with its cadence - Changes channel after the second unanswered reminder - Keeps the phone call for those still not replying → The daily hour is recovered and deliveries arrive as fast or faster. **Somebody who already delivered another way keeps being chased.** - Checks the file before the reminder goes out → Nobody receives an unfair chase. **Reminders go out daily and the supplier stops reading them.** - Spaces out the cadence → The nudge works again. **The reminder does not say exactly what is missing.** - Includes the outstanding list in the notice itself → The supplier delivers without writing to ask. **After five reminders nobody decides what to do.** - Sets a closing or escalation criterion → The file does not stay open forever. --- --- id: KB-CF-006 url: https://app.codecontract.io/help/use-cases-by-capability/onboarding-a-new-supplier idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-CF-005] citadoPor: [KB-IN-006, KB-CF-009, KB-CF-015, KB-CF-016, KB-CR-010] --- # Onboarding a new supplier _From "we picked them" to "they can invoice" without twenty emails in between._ **Responde a:** supplier onboarding process · what documents to ask a new supplier for · supplier approval · new supplier checklist Supplier onboarding is always the same five or six things, asked of the same kind of person. It is the case where having a process shows most: two weeks of emails become four days with nobody chasing anybody. ## What gets asked for, nearly always | Document | Blocks? | Expires | | --- | --- | --- | | Tax details and bank account | Yes | No | | Tax clearance certificate | Yes | 3 months | | Public liability insurance | Yes | 1 year | | Quality or sector certificates | Depends | Varies | | Invoicing contact | No | No | ## The order that works 1. **First what blocks you** — Without tax details you cannot even create them in your own system. First phase, on its own. 2. **Then what protects you** — Insurance and tax clearance. Second phase. 3. **Specifics last** — Sector certificates, which take longest because they depend on third parties. > [!IMPORTANT] > Bank details are fraud's favourite target: if an email arrives changing a known supplier's account, confirm it by phone on a number you already had, not the one in that email. > [!NOTE] > Saving the onboarding as a template the first time turns the second supplier into two minutes of work. It is the case where a template pays for itself fastest. **What if the supplier worked with us years ago?** Review what is still current: tax details probably are, insurance probably is not. **Can I let them invoice while something is missing?** You can, by marking it non-blocking. That is your call, and it is recorded. **Can I ask for everything at once?** You can, but delivery drops noticeably. Splitting is what most raises response. ## Ejemplos **A manufacturer onboards twelve suppliers a quarter, each taking two weeks.** - Builds onboarding as a three-phase process - Marks insurance and tax clearance as expiring → Onboarding drops to four days on average and renewals request themselves the following year. **A new supplier is created in purchasing and their documentation is requested three weeks later.** - Launches onboarding when the supplier record is created - Requests first the two documents that block the order - Adds the rest in a second phase → The first order does not wait for a complete file, and the file does not stay half done. **Each buyer asks the same supplier for a different list.** - Shares a single onboarding template → The supplier receives a coherent request and delivers once. **The supplier does not understand what each item is for.** - Adds a line of context per document → They reply without a preceding call. **Onboarding is approved and nobody records the expiries.** - Records validity when approving each document → The file is still true six months later. **Purchases go to a supplier who never completed onboarding.** - Checks the status before issuing the order → No order leaves for a supplier with no file. --- --- id: KB-CF-007 url: https://app.codecontract.io/help/use-cases-by-capability/onboarding-a-new-employee idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CF-002, KB-AD-003] citadoPor: [KB-LE-006, KB-CR-012, KB-CF-020, KB-CR-009] --- # Onboarding a new employee _Contract, paperwork and first-day training, without paper folders._ **Responde a:** new employee paperwork · sign the contract before they start · employee onboarding documentation · what documents to ask a new hire for Employee onboarding has an immovable date — their start day — and depends on a person who is not inside yet sending you things. It is exactly the case a phased process is for. ## Before day one - Signed contract. Starting unsigned is your problem, not theirs. - Identity document and social security number. - Bank details for payroll. - Qualifications, if the role requires them. ## On day one - Confidentiality and data protection agreement. - Equipment handover, with acknowledgement. - Mandatory health and safety training for the role. > [!WARNING] > This handles a person's identity document and bank details: ask only for what you genuinely need, store it where only the right people see it, and do not leave it circulating by email. > [!NOTE] > Sending the contract to sign three days ahead instead of handing it over on day one avoids the classic "they start today and have not signed yet" — which is commoner than it sounds. ## What expires Mandatory training and some medical checks lapse. Marking them at onboarding means the warning arrives on its own two years later, when nobody remembered. **Can they sign the contract from a phone?** Yes, and that is the norm before starting. **What about an urgent hire?** The process does not get in the way: send what blocks and the rest in parallel. **Can it be reused for renewals?** Yes, with a shorter version asking only for what changes. ## Ejemplos **A company brings in eight people in September.** - Launches onboarding for all eight three weeks ahead - Contracts are signed before day one - Training is recorded with an expiry date → All eight start fully signed up, and in two years the training renewal warning arrives on its own. **Somebody starts on a Monday and their contract is signed the following Thursday.** - Launches the process when the contract is agreed, not on arrival - Sends the contract and policies for signature before day one - Checks what is missing the day before → The person starts with a complete file and without spending their first day on paperwork. **Ten people are hired for a campaign and onboarding is done one by one.** - Launches the same process to all ten → Bulk onboarding does not consume the week. **A document is missing and nobody spots it until the inspection.** - Checks what is missing per person → The gap shows before a third party sees it. **Documentation expires and the person keeps working.** - Records expiries per person → The warning arrives before it bites. **Somebody joins and does not know what they have to sign.** - They receive the list of what is theirs → Onboarding completes without anyone explaining it. --- --- id: KB-CF-008 url: https://app.codecontract.io/help/use-cases-by-capability/responding-to-a-dispute idioma: en categoria: casos-por-funcionalidad audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-SC-004] citadoPor: [KB-CS-008] --- # Responding to a dispute _Gather in one afternoon what proves your side, with its dates._ **Responde a:** prove we delivered on time · a client dispute what evidence do i have · retrieve a case history · prepare documentation for litigation In a dispute what is argued is almost never what a document says: it is when it was known, who accepted it, and whether what you are showing now is what existed then. All three are answered with dates. 1. **Gather the sequence, not loose documents** — What was asked, what was delivered, what was approved, in what order. The sequence is the argument. 2. **Check the dates are trustworthy** — A date you set yourselves is worth less than one certified by a third party. 3. **Export with the trail** — A document without its delivery record is half the proof. ## What usually settles it | What is argued | What closes it | | --- | --- | | "You never told us" | The send and open records | | "That is not what we signed" | Verification of the signed document | | "You delivered late" | The delivery date, set by the system | | "We did not approve it" | The approval record, with name and time | > [!IMPORTANT] > Do not modify or reorganise anything once a dispute is live. Every change is logged, and a change made after the dispute always reads in the worst possible way, however innocent. > [!NOTE] > What helps most is usually the dullest thing: the record that an email was opened on the 4th, not the thirty-page contract. **How long is the trail kept?** According to your retention policy, set in the settings. **Can I give it straight to my lawyer?** Yes, with scoped access or a download carrying its dates. **Is a screenshot any good?** Not much. Anyone can make a screenshot; a verifiable document, no. ## Ejemplos **A client claims they were never told about a cost overrun.** - Retrieves the case sequence - Exports the send and open record for the notice → The record shows it was opened on the 4th, and the claim is withdrawn before lawyers get involved. **A client complains about a job from eight months ago and it has to be reconstructed from emails.** - Checks the file with its complete history - Provides what was delivered, its dates and who approved it → The response is prepared in an afternoon and rests on the trail, not on memory. **It is answered from memory and a contradicting fact turns up later.** - Checks before asserting → What is answered holds up. **The complaint reaches somebody who no longer handles that client.** - Checks who was involved and when → The response is prepared by whoever has the context. **It is answered and no record remains of what was sent.** - Records the response in the file → The next complaint starts from there. **The same complaint arrives twice through different routes.** - Checks whether it was already answered → The client receives a coherent response. --- --- id: KB-PR-003 url: https://app.codecontract.io/help/troubleshooting/my-emails-are-not-arriving idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-001, KB-CC-001] citadoPor: [KB-PR-013, KB-PR-020, KB-PR-021, KB-CC-004, KB-IN-004, KB-CC-002] --- # My emails are not arriving _Why they land in spam, and the three things that fix it for good._ **Responde a:** emails go to spam · the recipient does not receive my notices · configure the domain for sending · improve email deliverability If several different people say nothing arrives, it is neither coincidence nor bad luck: the recipient's mail system does not trust the sender. And trust is demonstrated, not requested. **En corto** - Sending from your own domain counts for far more than a generic one. - Sending has to be authorised on your domain, or the mail arrives looking suspicious. - A single all-caps subject line can send a whole batch to spam. ## The three things, by impact 1. **Use your domain** — Mail from @yourcompany.com passes filters a generic address does not. This changes the most. 2. **Authorise sending** — A few records have to be added to your domain saying this platform may send on your behalf. Whoever manages your domain does it in ten minutes. 3. **Mind the wording** — No capitals in the subject, no exclamation marks, no "URGENT". Filters read it literally. > [!WARNING] > Until the domain is authorised, the mail arrives claiming to be from you without being able to prove it. Gmail and Outlook filters treat that as suspicious, and rightly so. ## In the meantime An SMS or WhatsApp arrives even when email does not. It is not the underlying fix, but it unblocks today's case. **How do I know if a particular email bounced?** The case flags it, with the reason. **Can I ask people to add me to their contacts?** Yes, and it helps, but it does not replace authorising the domain. **How long before the change shows?** A few hours after the records are in place. ## Ejemplos **An accountancy firm finds half its notices are never opened.** - Switches to their own domain - Their IT person adds the authorisation records - Rewrites subject lines without capitals → Open rates go from 40% to 85% in a week. **Notices land in junk at one particular client.** - Asks them to add the sender to their safe list → The next notice reaches the main inbox. **A send goes to an old list and many addresses bounce.** - Cleans the contacts before the next round → Sending reputation does not suffer. **A corporate domain blocks everything external.** - Agrees with their IT to allow the sender → The block is resolved once for the whole company. **The supplier says it never arrived and it shows as sent.** - Checks the send time and resends → You learn whether the problem is sending or receiving. **Subject lines that look like marketing are used.** - Writes specific subjects saying what is requested → The email gets opened rather than dismissed. --- --- id: KB-PR-001 url: https://app.codecontract.io/help/troubleshooting/what-to-do-when-something-goes-wrong idioma: en categoria: problemas audiencia: usuario actualizado: 2026-08-12 tambienEn: [es, fr, pt] relacionados: [KB-PS-001, KB-TL-001, KB-PR-002, KB-PR-010] citadoPor: [KB-CO-006, KB-PR-003, KB-PR-002, KB-PR-004, KB-PR-005, KB-PR-006, KB-TD-013, KB-ET-003] enLaApp: https://app.codecontract.io/status --- # What to do when something goes wrong _The most common failures, how to fix them and what support needs to help you fast._ **Responde a:** what does error code E- mean · something is not working in Code Contract · the participant is not receiving the notice · how do I report a problem to support Almost everything that looks like a platform failure is one of four things, and three of them are fixable without writing to anyone. It is worth ruling them out in that order before raising it. **En corto** - If you see a code shaped like E-260812-4F2A, copy it: it identifies exactly what happened. - Before reporting, check the status page: if it is a general incident we already know. - Most "they never got the notice" cases are a mistyped email or phone number. - With three details — code, what you were doing, roughly when — support usually solves it first time. ## The error code, and why it matters so much **The error code** — When something genuinely fails, the screen gives you a code shaped like E-260812-4F2A. It is not decorative: it identifies that specific failure, with its time and context. Copy it and send it. With it, support finds the problem immediately; without it, they are guessing from your description. ## The most common failures | What you see | What it usually is | What to do | | --- | --- | --- | | The file will not upload | It is over 30 MB, the per-file limit | Split or compress it. If it is a scan, drop the resolution to 200 dpi | | The person says they received nothing | The notice is in their spam folder, or the contact has the wrong email or phone | Check the contact details and resend the notice by hand from the case | | The signature SMS code never arrives | The number on file is a landline or mistyped | Cancel the request, fix the phone number and send again | | Automatic reading got a field wrong | The document is blurry, rotated, or a photo taken in poor light | Correct the field by hand and, if you can, upload a better copy | | A screen will not load or goes blank | Usually a one-off connection problem | Reload. If it persists, check the status page before reporting | ## Before writing to support 1. **Check the status page** — If there is a general incident it is published there. In that case there is nothing to report: it is already being worked on. 2. **See whether it happens to anyone else on your team** — If it works for everyone else, the problem is in one specific piece of data or in a browser, and that narrows it down a lot. 3. **Try reloading and doing it once more** — One-off network glitches look a lot like real failures, and you cannot tell them apart without trying again. 4. **Note down the three details** — The error code if there is one, exactly what you were doing, and roughly what time. That is almost always enough. > [!NOTE] > "It does not work" is the description that wastes the most time. "Clicking Send on a signature request with two signers gives me code E-260812-4F2A, around 10:15" usually gets solved the same day. ## Frequently asked questions **Where do I find the error code?** It appears in the error message on the screen itself, usually at the end. It is shaped E-YYMMDD-XXXX. **What do I do if the notice email bounces?** The case flags bounces. Fix the address on the contact record and resend: the request does not have to be rebuilt. **Can I tell whether the other person opened the notice?** Yes. The case or the signature request shows when it was sent and whether the link was opened, which is what separates "it never arrived" from "they have not looked". **Automatic reading always fails on one type of document. Is that normal?** If it repeats with the same format it is worth telling us, saying which document type. A one-off failure on a bad photo is not the same as a pattern with a specific form. **Is anything lost if it fails halfway?** No. What was delivered stays delivered; whatever did not complete can be repeated without starting over. ## Ejemplos **Uploading a 45 MB scan, the screen warns that the file is too large.** - Rescan at 200 dpi instead of 600, or compress the PDF - If both versions really are needed, upload the light one and certify the heavy one separately → The document goes through and reads just as well: 200 dpi is more than enough for text. **A ticket is opened without saying which file it happened in.** - Copies the error code and the file before writing → Support does not have to ask for the same information twice. **The failure only happens to one person on the team.** - Tries the same thing with another account before escalating → A permissions problem is told apart from a system one. **An error appears and clears by itself shortly after.** - Notes the exact time and what was being done → The case can be investigated even if it no longer reproduces. **«It does not work» is reported with no further detail.** - Describes what was expected and what happened → The first reply is useful rather than a question. **Several people report the same thing through different channels.** - Gathers the cases into one ticket → The problem is worked once rather than five times. --- --- id: KB-PR-002 url: https://app.codecontract.io/help/troubleshooting/limits-and-what-to-expect idioma: en categoria: problemas audiencia: usuario actualizado: 2026-08-12 tambienEn: [es] relacionados: [KB-PR-001, KB-TL-001] citadoPor: [KB-PR-001, KB-DI-001, KB-DI-002, KB-CD-001] --- # System limits and what to expect _Sizes, formats and timings: worth knowing before you run into them._ **Responde a:** what is the maximum file size · I cannot upload a large file · which formats does the platform accept · how long does automatic reading take No system accepts anything of any size. Knowing where the limits are before you hit them saves a fair amount of frustration, especially when the person hitting them is your client on the other side. **En corto** - The per-file limit is 30 MB, and it is the same everywhere on the platform. - Any format for certifying; signing needs a PDF, and anything else is converted. - Automatic reading takes seconds, not hours. - A 200 dpi scan is plenty for reading text and weighs a fraction of the same at 600. ## File size The maximum per file is 30 MB, in every module and also for people uploading from outside. Almost everything that exceeds it is a scan at unnecessarily high resolution or an uncompressed phone photo. | If you have | Try | Why it works | | --- | --- | --- | | A huge scan | Rescan at 200 dpi | Plenty for reading text; at 600 dpi the file is several times bigger for no benefit | | A PDF full of photos | Compress the PDF | Image compression cuts the weight without touching the text | | A hundred-page document | Split it by section | It also makes finding the relevant part easier later | | A long video | Certify the video separately | SmartCheck accepts any format; the limit is still the size | ## Formats For certifying in SmartCheck any format works: sealing operates on the file, not on its content. For signing in Consigne a PDF is needed, and anything else is converted to PDF before it can be signed. In Trackline you can receive anything, though automatic reading works best with PDFs and sharp photos. ## Timings - Certifying: seconds, at upload time. - Automatic reading of a document: seconds, not minutes. - Notices by email, SMS or WhatsApp: sent immediately; delivery then depends on the carrier. - Effect of a configuration change: immediate, apart from the odd setting that can take up to a minute to propagate. > [!WARNING] > If automatic reading takes much longer than a few seconds, it is not thinking: something has failed. Reload and, if it repeats, note the error code. ## Frequently asked questions **Can I upload a file over 30 MB if it is important?** The limit is the same in all cases. The practical move is to lower the resolution or split it; you rarely lose anything useful. **How many documents can one case hold?** There is no cap aimed at normal use. What is worth watching is readability: a case with fifty documents is hard for anyone to review. **Is there a limit on how many people I can ask at once?** Not for ordinary use. If you are about to fire off hundreds of requests at once, mention it beforehand so nobody is surprised by the volume of sends. **What happens if my organisation runs out of credits?** Actions that consume credits — such as automatic reading — cannot run until you top up. Nothing already done is lost. ## Ejemplos **A supplier tries to upload a phone photo of a twelve-page contract and it will not go through.** - Ask them to use the photograph option inside the link rather than attaching a photo from their gallery - That way each page is processed separately and at the right size → The document goes through first time and arrives readable, without having to explain file compression to anyone. **An attempt is made to upload a file larger than allowed.** - Checks the limit before preparing the upload → The failure is avoided rather than discovered mid-upload. **An uncommon format is not accepted.** - Converts to an accepted format before uploading → The document goes in first time. **Reading takes longer than expected with a very long document.** - Leaves the process running and moves on → Processing time stops blocking a person. **A bulk load is planned without knowing how long it will take.** - Tries a small batch and estimates → The big load is scheduled on a real figure. **A limit is hit at the worst possible moment.** - Reviews the limits when designing the process → The design respects the constraints from the outset. --- --- id: KB-PR-004 url: https://app.codecontract.io/help/troubleshooting/i-cannot-sign-in idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-002, KB-PR-001] citadoPor: [KB-PR-027] --- # I cannot sign in _Password, second factor or closed account: how to tell which of the three it is._ **Responde a:** i cannot log in · i forgot my password · i lost my two-factor phone · my account does not work The error message rarely says which of the three things is failing, so work by elimination. All three have a fix and none needs a support ticket. | What you see | What is happening | What to do | | --- | --- | --- | | Incorrect username or password | The password, or a mistyped email | Reset the password from that same screen | | It asks for a code you do not have | Two-factor without the device | Use a recovery code, or ask an administrator | | It says you have no access | The account was closed or moved organisation | Talk to whoever administers your account | ## If you lost your two-factor phone 1. **Find the recovery codes you saved when you enabled it.** 2. **If you do not have them, ask an administrator in your organisation to restore access.** 3. **Re-enable two-factor on the new phone, and save the codes this time.** > [!IMPORTANT] > An administrator should only restore access after confirming by some other means that it is you — a phone call, in person. An email asking for a reset is exactly what someone impersonating you would send. > [!WARNING] > If you are the only administrator and you lose your second factor, nobody inside can help you. Which is why there should always be two. **Does the account lock after many attempts?** It slows down temporarily. That is a protection, not a permanent lock. **Can I sign in from another computer?** Yes, the account is not tied to a device. **What if my company uses corporate sign-in?** Then the problem is with that account, not here: your IT people handle it. ## Ejemplos **Someone changes phone and loses their authenticator app.** - Asks their company administrator for a reset - She phones him to confirm it is him - Re-enables it and saves the codes → He is back in within ten minutes, and next time will not depend on anyone. **The password is tried several times and the account locks.** - Uses recovery instead of insisting → The lockout is avoided on the second attempt. **The second factor is on a phone that has been lost.** - Contacts the administrator to recover it → Access is restored without switching security off. **Somebody signs in with a different email from their account.** - Checks which address the account was opened with → The commonest case is ruled out before escalating. **An account was closed when the person left the company.** - Confirms the status with the administrator → The answer takes a minute rather than several attempts. **The password is saved in the browser and has changed.** - Updates it wherever it was saved → The problem does not return the next day. --- --- id: KB-PR-005 url: https://app.codecontract.io/help/troubleshooting/i-cannot-upload-a-file idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-003, KB-PR-001] citadoPor: [KB-DI-007, KB-PR-009, KB-PR-015, KB-PR-022] --- # I cannot upload a file _It stalls, errors, or refuses the file: the causes by frequency._ **Responde a:** error uploading a document · the upload stalls halfway · it will not accept my file · the pdf will not upload It is nearly always size or connection. Before going in circles, check these four in order. | Symptom | Likely cause | Fix | | --- | --- | --- | | Stops at 90% and goes no further | Unstable connection | Retry on wifi or cable; the upload resumes where it was | | Says it is too large | Over 30 MB | Rescan at 300 dpi or split the document | | Says the file is not valid | It is damaged or an unusual format | Open it first: if your computer cannot either, the file is broken | | Nothing happens when clicking | A browser blocker | Try another window or another browser | ## If the file is damaged A PDF that will not open on your computer will not upload either. It usually happens when a file was half-copied from a USB stick or downloaded from an interrupted email. Ask for it again: there is no way to recover it from here. > [!NOTE] > Uploading twenty files at once over a slow connection fails more than uploading five at a time. On a poor connection, go in batches. > [!WARNING] > If a file was rejected on security grounds, do not retry or rename it: it means there is something inside that should not be. Check where it came from first. **Is progress lost if it cuts out halfway?** No, it resumes. It is only lost if you close the tab. **Can I upload from a phone?** Yes, including photos taken on the spot. **Is there a limit on how many at once?** Practical, not technical: the more there are, the longer it takes and the likelier the connection fails. ## Ejemplos **An administrator cannot upload a 60 MB scan of a deed.** - Rescans at 300 dpi in greyscale → It drops to 11 MB and uploads first time. **The upload cuts out halfway on an unstable connection.** - Retries from a stable network → The file goes in without splitting anything. **The file is over the size limit.** - Compresses or splits the document → It uploads without losing content. **An attempt is made to upload a whole folder at once.** - Uploads the files, not the folder → The error disappears without changing browser. **The file name contains unusual characters.** - Renames it before uploading → The upload stops failing for no apparent reason. **Upload happens from a phone and the app closes.** - Retries with the screen awake until it finishes → The upload completes first time. --- --- id: KB-PR-006 url: https://app.codecontract.io/help/troubleshooting/something-failed-and-i-got-a-code idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-001, KB-CD-002] citadoPor: [KB-PR-009, KB-PR-010] --- # I got an error with a code _What that code is, why it is worth copying, and what to say when asking for help._ **Responde a:** what does the error code mean · i get an error when saving · how do i report a bug · error with reference e- When something genuinely fails, the screen gives you a code in this shape: `E-260813-4F2A`. It is not decoration: it is the exact reference for what happened, with its time and context, stored on the platform side. **En corto** - Copy it before closing the message. Without it, what happened has to be reconstructed. - It contains none of your data: it can be emailed safely. - With the code, support goes straight to the fault instead of asking you ten questions. ## What to say when asking for help - The code, exactly as shown. - What you were trying to do, in one sentence. - Whether it happened once or repeatedly. That is enough. No screenshots or long explanations needed: the code already carries what the system was doing at that moment. ## Before reporting it 1. **Retry once: some failures are momentary.** 2. **Try another tab, to rule out the browser.** 3. **If it happens again, then report it, with the code.** > [!NOTE] > An error with a code means the platform knows something went wrong and has recorded it. That is better than a silent failure, even if it does not feel like it at the time. > [!WARNING] > If the failure happens while paying or charging credits, do not repeat the operation several times before asking. Report it with the code. **Is my work lost?** It depends where it failed. The code says. **Can I look the code up myself?** The technical detail is for support. You provide the reference. **How long is it kept?** Long enough to investigate it comfortably. ## Ejemplos **Saving a process throws an error with a code.** - Copies the code - Retries and it fails again - Emails support with the code and one sentence → It is resolved without the usual "which browser?, what time was it?" round. **The error notice is dismissed without noting the code.** - Copies the code before dismissing → Support locates the specific case in seconds. **A cropped screenshot is sent where the code is not visible.** - Includes the code in the message text → No second screenshot has to be requested. **The same code appears several times in a week.** - Reports the cases together with their times → The pattern is visible rather than treated as isolated incidents. **The error is reported days later.** - Writes the same day, giving the time → The logs still allow reconstructing what happened. **Two people report the same code separately.** - Checks whether a case is already open → Duplicated support work is avoided. --- --- id: KB-PR-007 url: https://app.codecontract.io/help/troubleshooting/i-cannot-see-what-my-colleague-can idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-ET-005, KB-ET-006] citadoPor: [KB-PR-011, KB-PR-012, KB-PR-014] --- # I cannot see what my colleague can _It is almost always permissions, and it takes two minutes if you check the right thing._ **Responde a:** a document appears for someone else but not me · i have no access to a case · different permissions between colleagues · i cannot see the settings section It is one of the few problems that is almost never a fault: the system is doing exactly what it was told, only nobody remembers telling it. ## The three causes, by frequency | Cause | How to spot it | Who fixes it | | --- | --- | --- | | You are in a different team | You see all of yours, none of theirs | An administrator adds you to the team | | Your profile does not reach it | You see the case but not one part | An administrator adjusts the permission | | The document is in another organisation | It does not appear even in search | Switch organisation at the top | ## Worth checking before asking for help 1. **Look at the top to see which organisation you are in. If you run several, it is the silliest and commonest cause.** 2. **Ask your colleague for the exact path, not the document name.** 3. **Check whether you see the case but not the document, or neither: they are different problems.** > [!IMPORTANT] > Not seeing something is not always an error to correct. Some documents — payroll, health data, another client's file — are scoped deliberately. Before asking for access, check whether you actually need it. > [!WARNING] > If what you cannot see is the organisation settings, you are not an administrator. That is usually correct: not everyone should be. > [!NOTE] > If this happens often in your team, the permission split is poorly designed and deserves half an hour of review, not ten separate requests. **Can I find out who does have access?** An administrator can see it. **Can access be granted to a single document?** Normally access is granted to the case or the team. **Would Marta find it for me?** No. It inherits your permissions: it will not show what you cannot see. ## Ejemplos **Someone cannot find a case their colleague has open on screen.** - Looks at the top: they are in another group company's organisation - Switches → The case appears immediately; it was never a permissions problem. **One colleague sees a file and another does not.** - Compares the two sets of permissions → The difference surfaces without touching anything else. **Somebody changes department and loses access to their work.** - Checks which group they now belong to → Access follows the role rather than the person. **A document does not appear in one person's search.** - Checks whether they have access to that file → A search fault is ruled out before reporting it. **An internal link is shared and the other person cannot open it.** - Grants them access to the file instead of forwarding the document → Access is recorded and the file is not duplicated. **Broad permissions are granted to get past the problem.** - Grants only the file that is needed → The problem is solved without opening more than necessary. --- --- id: KB-PR-008 url: https://app.codecontract.io/help/troubleshooting/i-sent-something-by-mistake idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-008, KB-CO-011, KB-PR-025] citadoPor: [KB-PR-016] --- # I sent something by mistake _What to do in the first ten minutes, while it can still be fixed cleanly._ **Responde a:** i sent a document to the wrong person · cancel a send just made · i sent confidential data by mistake · recall a send The instinct is to wait and see whether anyone notices. That is the worst option: the sooner it is cut off, the fewer people will have opened it and the cleaner the explanation. ## The first ten minutes 1. **Cut off access** — Void the send. The link stops working immediately, even though the email is already in their inbox. 2. **Check whether it was opened** — The case tells you. An unopened email is not the same as a downloaded document. 3. **Tell them yourself** — A short message saying it was a mistake and to ignore the previous one. Hearing it from you changes how it lands entirely. ## Depending what was inside | What you sent | What else to do | | --- | --- | | A wrong document, no third-party data | Void and resend the right one | | Another person's personal data | Tell whoever handles data protection in your company | | Bank or identity details | Also tell the affected person | | A document to your client's competitor | Talk to your manager before writing anything | > [!IMPORTANT] > If what was sent contained third parties' personal data, it is not merely a work error: there may be specific notification duties on short deadlines. Tell whoever handles data protection in your company that same day, even if you believe it was never opened. > [!WARNING] > Voiding does not delete the email from anyone's inbox. It cuts off access to the document, which is what matters, but the message is still there. > [!NOTE] > If the error came from a badly filtered list, review the list before relaunching. Resending in a hurry on the same list repeats the mistake, now with context. **Can I tell whether they downloaded it?** Yes, accesses are logged. **Do I get the credit back?** No, the send was already consumed. **Is my voiding recorded?** Yes, with the time and the reason you write. ## Ejemplos **One employee's amendment goes to another employee's address.** - Voids the send within five minutes - Confirms it was never opened - Writes to the person explaining the error - Tells whoever handles data protection → The document was never seen and the notification is made the same day. **A request goes to the wrong contact.** - Cancels the send and corrects the recipient → The error closes before the other side opens it. **A document is sent with a wrong figure.** - Warns the recipient and sends the corrected version → The correction arrives before the confusion does. **A round goes out to a hundred contacts by mistake.** - Stops what has not gone yet and warns about the rest → The error's reach is limited within minutes. **A draft is sent for signature instead of the final version.** - Cancels the request before it is signed → No signature lands on the wrong document. **The mistake is discovered the next day.** - Warns anyway and puts what happened on record → The trail explains the send rather than leaving it without context. --- --- id: KB-PR-009 url: https://app.codecontract.io/help/troubleshooting/it-is-slow-or-will-not-load idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-005, KB-PR-006] citadoPor: [KB-PR-010, KB-TD-013] --- # It is slow or will not load _How to tell in two minutes whether it is you, your network, or us._ **Responde a:** the platform is very slow · the page will not load · it hangs on loading · connection problems with the platform Before writing to anyone, two minutes of elimination saves a whole conversation. The cause is usually closer than it seems. ## Elimination, in order 1. **Try another tab or a private window** — If it works there, it is a browser extension or a stuck session. It is the commonest cause. 2. **Try mobile data** — If it works on your phone but not on the office wifi, it is your network — usually a firewall or proxy. 3. **Ask a colleague** — If it works for them in the same office, it is your machine. If it works for nobody, it is something else. | What you find | What it is | Who to tell | | --- | --- | --- | | Works in a private window | An extension or the cache | Nobody: closing and reopening fixes it | | Works on mobile data | The office network | Your IT person | | Works for nobody in the office | The network, or us | Your IT person first | | Works for nobody, anywhere | Us | Support, and check the status page | ## What is slow without anything being broken - Uploading fifty files over a slow connection: go in batches of five. - Opening a list of thousands of cases unfiltered: filter first. - A two-hundred-page PDF: it is slow to open, not frozen. > [!NOTE] > If something hangs but the rest of the internet is fine for you, try the private window first. Nine times out of ten that is it. **Is there a page showing whether it is down?** Yes, the status page. It is the first thing to check if it works for nobody. **Does clearing the cache help?** Yes, and that is what you are testing with a private window. **What do I tell support?** What you were doing, from where, and which elimination steps you already did. That saves half the questions. ## Ejemplos **One person cannot get file uploads to load while the rest of the office can.** - Tries a private window and it works - Disables a blocking extension → Resolved in two minutes without opening a ticket. **It is slow on only one machine in the team.** - Tries another machine before reporting → The problem is located in a minute. **It is slow at the same time every day.** - Notes the time and tries outside that window → A load peak is told apart from a fault. **One particular screen is slow and the rest are not.** - States exactly which screen when reporting → Diagnosis starts where it should look. **It is slow over the company VPN.** - Tries without it to compare → You learn whether the bottleneck is your own network. **Slowness is reported with no detail.** - Provides time, screen and whether others see it too → The first reply is already a diagnosis. --- --- id: KB-PR-010 url: https://app.codecontract.io/help/troubleshooting/deciding-whether-a-problem-is-serious idioma: en categoria: problemas audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-006, KB-PR-009] citadoPor: [KB-PR-001] --- # Deciding whether a problem is serious _When it can wait until tomorrow and when to write immediately._ **Responde a:** is this urgent or can it wait · when should i contact support · what to do when something does not work · how serious is this issue Not everything that fails is urgent, and treating everything as urgent means what genuinely is gets lost in the noise. The question that sorts it is simple: is someone outside waiting, or is money or a deadline involved? ## The three levels | Level | How to recognise it | What to do | | --- | --- | --- | | Now | Affects third parties, a payment or a legal deadline | Write with the error code, without waiting to reproduce it | | Today | Blocks you but does not leave the organisation | Rule out your own side first, then write | | Whenever | Annoying but there is a way to carry on | Note it and group it with others | ## What is almost always "now" - A send that went to the wrong person. - A charge taken twice, or one that does not add up. - A document visible to someone who should not see it. - Anything blocking a signature on the last day of a deadline. > [!IMPORTANT] > If the fault exposed third parties' data to someone who should not see it, it is not merely a technical issue: tell whoever handles data protection that same day. There are duties with short deadlines and they start running from when you know. > [!WARNING] > Do not retry a failed payment or charge, not even "just to check". Report it with its code; retrying is how you end up with two charges instead of one. ## What to say, at any level The error code if there was one, what you were trying to do in one sentence, and whether it happened once or repeatedly. That is enough: the code already carries what the system was doing. > [!NOTE] > If you hesitate between "today" and "whenever", check whether someone outside is waiting. That raises real urgency more than anything, even when it feels minor to you. **Should I report it even if it was my mistake?** Yes. Half of what gets reported ends up improving something for everyone. **What if I cannot reproduce it?** Report it anyway with the code: that is where what happened is recorded. **Is there a status page?** Yes, and it is the first thing to check if it works for nobody. ## Ejemplos **Someone sees a charge taken twice and is about to retry the operation.** - Stops - Copies the error code - Reports it as urgent → It is resolved with a single charge instead of three and a refund. **A fault affects one person and there is a workaround.** - Reports it and continues the other way → Work does not stop for something that can wait. **A fault blocks a send due tomorrow.** - Writes stating the deadline → The urgency is understood without having to insist. **Something looks wrong but the data is right.** - Checks whether it affects what is delivered → A display problem is told apart from a content one. **A fault affects data going to a third party.** - Treats it as urgent and raises it → It is stopped before something incorrect goes out. **Every fault is escalated as critical.** - Uses a written criterion to decide → Urgent things are handled sooner because they do not compete with everything else. --- --- id: KB-PR-011 url: https://app.codecontract.io/help/troubleshooting/it-will-not-let-me-do-something idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-007, KB-ET-011] citadoPor: [KB-PR-026] --- # It will not let me do something _A greyed-out button, a warning, or a screen that is missing: the four causes._ **Responde a:** the button is disabled · it will not let me send · i cannot create a process · a warning appears and i cannot continue When something will not go through it is almost never a fault: a condition is missing. Four causes explain practically every case, and they are told apart by what the screen says. | What you see | What is missing | Who fixes it | | --- | --- | --- | | Insufficient balance warning | Credits for that action | Whoever can top up, usually an administrator | | Licence warning | The licence has expired or been cancelled | Whoever handles the commercial relationship | | The button is not there | Permission for that action | An administrator in your organisation | | A contact detail is missing | Phone, email or a required field | You, on the contact record | > [!IMPORTANT] > The first two are worth telling apart: with no balance you top up and carry on; with an expired licence, topping up does not solve it — you need whoever handles the commercial relationship, and until then nothing can run. ## Before writing to anyone 1. **Read the whole warning: it nearly always says which of the four it is.** 2. **If a button is missing, ask whoever administers your account before support.** 3. **If the warning carries an error code, copy it: that is no longer a missing condition, it is a fault.** > [!WARNING] > A missing button is usually correct, not a problem. Not everyone needs to be able to delete, invite or change settings: if you are missing something you genuinely need for your work, that is a permissions conversation, not a support ticket. > [!NOTE] > Warnings of this kind do not lose what you were doing. What was prepared stays; it is only waiting on the missing condition. **Can I find out which permission I lack?** An administrator can see it on your record. **Do I lose what I had prepared?** No, it waits. **What if the warning says nothing clear?** Then yes, to support with the error code. ## Ejemplos **Someone cannot launch a send and assumes it is broken.** - Reads the warning: insufficient balance - Tells the administrator, who tops up → Launches the send ten minutes later, with no ticket opened. **The button is greyed out and nobody knows why.** - Checks whether something must be completed first → The missing condition becomes visible instead of assuming a fault. **An option does not appear in the menu.** - Checks whether the permission fits that role → What is absent is explained without writing to support. **A warning prevents saving and is not understood.** - Reads which field the warning points to → The block clears by correcting that field. **It works in one file and not in another.** - Compares the status of both → The difference is the status, not a fault. **Somebody asks for administrator rights for a one-off task.** - Checks which specific permission is needed → The minimum is granted rather than everything. --- --- id: KB-PR-012 url: https://app.codecontract.io/help/troubleshooting/there-are-two-identical-documents idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-007, KB-DI-006] citadoPor: [KB-PR-016, KB-PR-018] --- # There are two identical documents _Duplicates: why they appear, which to keep, and when they are not duplicates at all._ **Responde a:** i have the same document twice · removing duplicates · which of the two copies to keep · document uploaded twice by mistake Two entries appear that look like the same document, and the instinct is to delete one. Before doing that, check which of four situations it is, because in two of them deleting is exactly the wrong move. ## The four situations | Situation | How to recognise it | What to do | | --- | --- | --- | | Uploaded twice in a row | Same name, same time, same person | Keep one | | Two people uploaded it | Different person, different times | Keep one, and say who maintains it | | They are different versions | Different dates or content | Keep both: the earlier one proves what existed | | Same paper in two matters | It appears in two files | Keep both, and it is not a problem | > [!IMPORTANT] > The third causes damage. Deleting the old version because it is "out of date" removes the proof of what the document said when someone took a decision with it in front of them. Old versions do not get in the way: mark them superseded and keep them. ## Which to keep when you must choose 1. **The one linked to the file** — The loose one has no context and probably nobody will find it. 2. **The one that read well** — If one is a skewed photo and the other the original PDF, there is no contest. 3. **The one with a provable date** — If one is sealed and the other is not, the sealed one is worth more. 4. **And when in doubt, neither** — A duplicate is an annoyance; a wrong deletion cannot be undone. > [!WARNING] > Watch the fourth row. A certificate appearing in the files of three different sites is not a duplicate: it is one document serving three purposes. Deleting it from two leaves two incomplete files. ## How they stop appearing **En corto** - A clear place for each thing: half of all duplicates are born of doubt. - Whoever receives a document by email uploads it, instead of forwarding it to two more people. - And versions treated as versions rather than new files. > [!NOTE] > Every upload consumes, repeats included. That is no reason to spend time checking before uploading, but it is a reason not to automate an import that uploads the same thing repeatedly. **Can deleted material be recovered?** It depends on when and on your retention policy. Do not assume. **Can I link the same document in two places?** Yes, and it beats uploading it twice. **Is there a way to detect them?** Identical content produces the same fingerprint; two identical files are recognisable even under different names. ## Ejemplos **Someone finds the same insurance policy twice and deletes the older one.** - Checks first and finds they were two different versions - Marks the old one superseded instead of deleting → Keeps proof of what cover existed when last year's incident happened. **The same document appears twice because two people uploaded it.** - Keeps the one in the right file and deletes the other → One document and one reference remain. **There are two similar versions and one is signed.** - Keeps the signed one and marks the other as a draft → Nobody works again on the version with no standing. **Two documents look identical and carry different dates.** - Checks the validity of each → They turn out to be renewals rather than duplicates. **A duplicate is deleted and a link in another file breaks.** - Checks where it is referenced before deleting → Deleting does not break anything elsewhere. **The supplier resends the same thing just in case.** - Shows them what is already recorded as received → They stop sending copies for fear it never arrived. --- --- id: KB-PR-013 url: https://app.codecontract.io/help/troubleshooting/they-tell-me-the-link-does-not-work idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-003, KB-CO-006, KB-PR-015] citadoPor: [KB-CD-016, KB-PR-020, KB-PR-027] --- # They tell me the link does not work _Five causes, and the commonest has nothing to do with the link._ **Responde a:** the signing link does not work · the supplier says they cannot open the link · expired link what do i do · they cannot access the document i sent "The link doesn't work" is one of the biggest time sinks, because it covers five different situations and only one is fixed by sending another link. ## The five causes, by frequency | Cause | How to recognise it | What to do | | --- | --- | --- | | They opened an old link | They got two emails and clicked the first | Tell them to use the latest email | | The link expired | The send's window passed | Resend: a new one is generated | | They already used it | It shows as signed or supplied | Check: it may already be done | | Their mail client broke the link | It arrives split across two lines | Send it by another channel | | They are not the right person | Forwarded by a colleague | Send it to whoever must act | > [!IMPORTANT] > The first is by far the commonest and the most invisible: if you sent a reminder, they have two emails and no reason to open the right one. Telling them "use the latest" resolves half the cases in one message. ## Before resending, check this 1. **Whether it is already done** — It happens more than you would think: they did it and report out of habit. 2. **Who opened what** — If it shows opened by someone else, the link works and the problem is the recipient. 3. **And whether the send is still live** — An expired send is not fixed by insisting: it must be sent again. > [!WARNING] > The fifth causes the most confusion. If a colleague forwards the email to someone else, the link still belongs to the first person: they may open it and see something that is not theirs, or be unable to do anything. The answer is not more forwarding: it is sending to the person who must act. ## How to stop it happening **En corto** - Send to the named person, not a shared mailbox. - Say in the message what must be done, so it is not forwarded blindly. - And do not send the same document twice: a reminder yes, a new send no. > [!NOTE] > Every resend consumes like the first. Checking the status before resending is not only efficiency: these are paid actions that often were not needed. **How long does a link last?** It depends on the send; reminders keep it reachable within the window. **Can someone else sign with that link?** The link belongs to whoever it was sent to; if another person must sign, send it to them. **What if they say nothing arrived?** That is a different problem, checked through the send status. ## Ejemplos **A supplier insists the link does not work after two reminders.** - They are told to open the most recent email → They sign immediately: they had been opening the first send's link. **The recipient opens the link from a forwarded email.** - Sends them the link directly → Access works because it is issued in their name. **The link was opened weeks ago and has expired.** - Resends the request from the same file → The new link arrives without rebuilding anything. **The supplier's mail client truncates the link.** - Sends it another way or as plain text → The link arrives whole and works. **The supplier already completed the request and tries again.** - Confirms it is already delivered → The doubt closes without issuing a new link. **The link is tried from a network that blocks external domains.** - Tries from another connection → The block is located before it is reported. --- --- id: KB-PR-014 url: https://app.codecontract.io/help/troubleshooting/something-appeared-that-i-did-not-upload idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-007, KB-DI-010] citadoPor: [KB-PR-022] --- # Something appeared that I did not upload _Documents that appear from nowhere: where they really come from and what to do with them._ **Responde a:** a document i did not upload appeared · where did this file come from · who uploaded this · documents arriving in the file on their own A document appears in a file and nobody on the team remembers uploading it. Before worrying, check where it came from, because there are four possible origins and three are entirely normal. ## The four origins | Origin | How to recognise it | Is it normal | | --- | --- | --- | | The third party you asked supplied it | It shows as uploaded by the external participant | Yes, exactly what you wanted | | A colleague uploaded it | Their name and time are recorded | Yes | | The process itself generated it | A receipt, an acknowledgement, a signed document | Yes | | None of the above | No expected author recorded | Here it is worth looking | > [!IMPORTANT] > The first is the answer in the vast majority of cases, and it surprises because whoever requested the document is not always who sees it appear. That is normal operation: the third party supplies and the file updates without anyone on the team touching anything. ## How to check, in a minute 1. **Look at who and when** — The activity log shows who uploaded it, from where and at what time. 2. **Check whether there was an open request** — If there was, it is almost certainly the answer to it. 3. **And if it does not add up, ask before deleting** — Deleting a document supplied by a third party means asking them again. > [!WARNING] > The mistake to avoid is deleting it as a precaution. If the supplier provided it and it is removed, the request stays open, the supplier believes they already sent it, and an argument starts that nobody needs. ## When it genuinely does not add up **En corto** - If the author is neither from your organisation nor an invited participant, tell an administrator. - Do not delete it: it is more useful as evidence than gone. - And review which external access is still active, which is usually the explanation. The third line is nearly always the answer: someone outside granted access months ago and never withdrawn. It is not a security incident; it is an overdue clean-up. > [!NOTE] > A document appearing without you uploading it is one of the signs the system is working: it means the collecting work stopped being yours. **Can we see which device it came from?** The log keeps the action's context; an administrator can consult it. **What if the document does not belong to that file?** Move it to the right one and tell whoever uploaded it; it is usually human error. **Can someone without permission upload?** Only someone with access or an open request in their name. ## Ejemplos **A manager sees a new certificate in a file and suspects a mistake.** - Checks the log: the supplier uploaded it answering the request → Closes the request instead of deleting the document and asking again. **A document appears that nobody on the team remembers uploading.** - Checks who uploaded it and when → The origin is clarified without speculation. **An external participant provides something without warning.** - Checks the participant record → You learn which supplier sent it. **A document arrives that does not belong to that file.** - Moves it to the right file and gives notice → The error is corrected before anyone uses it. **An automated process creates documents that come as a surprise.** - Checks which integration generates them → The behaviour is understood and adjusted. **There is a suspicion somebody accessed without permission.** - Checks the audit trail → The suspicion is confirmed or dismissed with data. --- --- id: KB-PR-015 url: https://app.codecontract.io/help/troubleshooting/the-document-will-not-open-or-looks-wrong idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-005, KB-DI-003] citadoPor: [KB-PR-013] --- # The document will not open or looks wrong _Five causes, from the silliest to the most awkward, and what to do about each._ **Responde a:** cannot open an uploaded pdf · the document displays black · corrupt file what do i do · pdf will not load in the browser A document that will not open creates instant distrust in the system, and it is hardly ever the system's fault. These are the five causes, in the order worth ruling them out. ## The five causes | Cause | How to recognise it | Solution | | --- | --- | --- | | The file was already broken | It will not open on the sender's computer either | Ask them to regenerate it | | It is password protected | It asks for a key or shows blank | Ask for an unprotected version | | An unusual format | Rare extension or from one specific program | Convert to PDF before uploading | | A browser problem | It opens when downloaded but not on screen | Download; and try another browser | | It looks wrong but is fine | Inverted colours, very dark, rotated | That is the scan, not the file | > [!IMPORTANT] > The second is commoner than expected with official and banking documents: they arrive protected and the sender does not even remember. A protected PDF can be stored, but it cannot be read for data extraction or content search. ## What to do before going back to them 1. **Try downloading it** — Many cases are display problems, not file problems. 2. **Ask whether it opens for the sender** — One message rules out 40% of cases. 3. **And check the size** — A few-kilobyte file that should be several megabytes arrived incomplete. > [!WARNING] > Do not delete the original even if it seems useless. If the file is corrupt, the file itself is evidence that you were sent something illegible on that date, and sometimes that is the information that matters. ## What prevents most of them **En corto** - Ask for PDF wherever possible instead of program-specific formats. - Reject password-protected files in the request, not afterwards. - And say that scans should be taken straight on and well lit, which resolves the fifth cause entirely. > [!NOTE] > If the document opens but does not respond to content searches, it is not broken: it is an unread scan. That is a different thing with its own solution. **Can I ask them to resend without annoying them?** Yes, and say why: "it arrives illegible" is understood without difficulty. **What if the original no longer exists?** Keep what you have and note the circumstance; sometimes it is all there is. **Are there formats it will not accept?** The usual ones are fine; for anything unusual, converting to PDF is safest. ## Ejemplos **A team writes off a certificate that will not open.** - Notices it is 4 KB and asks for it to be resent → Gets the complete file the same day instead of raising a technical incident. **The PDF opens blank in one particular viewer.** - Opens it in another viewer to compare → You learn whether the problem is the file or the program. **The document is password protected.** - Asks the supplier for an unprotected version → The document can be read and processed. **A scan comes out rotated and cannot be read.** - Rotates it and uploads again → Automatic reading works first time. **The file was corrupted on upload.** - Uploads it again from the original → An incomplete upload is ruled out before reporting. **An old format does not display correctly.** - Converts it to a standard format → The document looks the same for everyone. --- --- id: KB-PR-016 url: https://app.codecontract.io/help/troubleshooting/i-uploaded-it-to-the-wrong-file idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-012, KB-PR-008] citadoPor: [KB-PR-017] --- # I uploaded it to the wrong file _A document in the wrong place: what to do, in what order, and what not to touch._ **Responde a:** i uploaded a document to the wrong place · move a document to another file · document in the wrong project · delete and re-upload a file It happens to everyone and is rarely serious, but the order in which you fix it does matter — especially when the wrong file belongs to another client or supplier, which is when it stops being a slip and becomes something worth handling properly. ## What to do, in this order 1. **Check who could have seen it** — The log says whether anyone opened it between upload and now. That comes first, not last. 2. **Move it rather than deleting and re-uploading** — Moving keeps the trail; delete-and-resubmit creates a new document with no history and consumes again. 3. **Check whether it triggered anything** — A document in a file may have closed a request or fired a rule. 4. **And note it if it had consequences** — If someone outside actually saw it, that gets recorded: it is information, not a confession. > [!IMPORTANT] > The first step is the one hardly anyone takes and the only one that changes the response. If the document sat ten minutes in another client's file and nobody opened it, it is a slip; if someone from that other company viewed it, this is no longer a filing problem — it is access to documentation that was not theirs, and that is managed, not glossed over. ## What not to do | Not this | Why | | --- | --- | | Delete it and carry on as if nothing happened | If someone saw it, the trail is the only thing that explains what occurred | | Re-upload without moving the original | Two copies in two places and one of them is surplus | | Leave it "because nobody looks there anyway" | Someone does: files get audited and shared | | Fix it on Monday | The longer it sits, the more people could have seen it | > [!WARNING] > The serious case is uploading one client's documentation into another's file. It is not just a filing error: it is a third party's documentation visible to someone who should not see it. If that happens, beyond moving it, check who accessed it and assess whether anyone must be told — and that assessment is not made by whoever slipped, it is made by an administrator. ## How it happens less **En corto** - Upload from inside the file, not from a general screen. - File names that do not resemble each other — two sites for the same client are the classic. - And review what you uploaded when you finish, which costs ten seconds. > [!NOTE] > If the wrong document closed a request that was still open, reopen it when moving: otherwise the third party believes they have delivered and you keep waiting for something that will never arrive. **Is anything lost when moving?** No: it keeps its history, its date and who uploaded it. **What if someone already signed it there?** Then do not simply move it: check first, because the signature relates to that send. **Does moving a document consume?** Moving is not uploading. What consumes is re-uploading, which is why moving is better. ## Ejemplos **Someone uploads a contract into another client's file and deletes it to re-upload.** - Checks first who accessed it and moves the document instead of deleting → Keeps the full trail and confirms nobody outside ever saw it. **The document goes into another supplier's file.** - Moves it before anyone approves it → The wrong file never counts it. **It had already been approved in the wrong place.** - Moves it and reviews the status of both files → Both end up reflecting reality. **It is uploaded to another client's file.** - Withdraws it and warns whoever could have seen it → Improper access is cut off as soon as possible. **It is deleted rather than moved and the trail is lost.** - Moves instead of deleting and re-uploading → The document's history survives the move. **Nobody knows whether the supplier sent it twice.** - Checks who provided it and when → An internal error is told apart from a duplicate from outside. --- --- id: KB-PR-017 url: https://app.codecontract.io/help/troubleshooting/they-ask-me-for-a-document-i-do-not-have idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-011, KB-PR-016] citadoPor: [KB-TL-022] --- # They ask me for a document I do not have _Before saying it is missing, three checks. And if it genuinely is missing, how to answer._ **Responde a:** cannot find a document i am asked for · what to do when i do not have what is requested · replying that we do not have a document · document that never existed Someone asks for something and it does not turn up. Before replying, separate four very different situations, because the right answer differs in each and saying "we do not have it" when it is actually something else complicates what was a formality. ## The four situations | Situation | How to tell | What to answer | | --- | --- | --- | | It is there and you cannot find it | It appears when searching by identifier or content | Nothing: hand it over | | It is somewhere else | An adviser, forwarder or installer holds it | Request it and say when it will arrive | | It existed and was not kept | There is a trace of it but not the document | Say so, with whatever is on record | | It never existed | It was not requested, not done, or did not apply | Say so clearly, and why | > [!IMPORTANT] > The last two are different and usually get merged in the reply. "We did not keep it" and "it was never issued" mean very different things to whoever asks: the first is a filing failure, the second may be correct and sufficient. **Answering a bare "I do not have it" turns the second into the first** in the reader's eyes. ## The three checks before saying it is missing 1. **Search by what it says, not by its name** — An identifier inside the document finds what a badly chosen title hides. 2. **Check whether a third party who worked with you holds it** — Adviser, installer, forwarder, laboratory: the number one cause of "we do not have it". 3. **And check you are looking in the right place** — Another organisation, another file, or without permission to see it. > [!WARNING] > The nuance that changes the tone of the reply: **an explained absence is not the same as silence**. "There is no record because it was not required at that date" or "we did not keep it; the applicable retention was X years and this predates that" are complete answers. What looks bad is not the gap: it is answering "it does not appear" without saying why, because the reader will fill the gap with the worst available explanation. ## If the request comes from an inspection or an auditing client **En corto** - Answer what is asked, no less and no more. - Provide what you do have on that matter even if it is not exactly what was requested. - And keep a record of what was answered and when. The second helps most: if the certificate is missing but you hold the delivery note, the check record and the supplier's email, that does not replace the document but shows the control existed. And that difference weighs. > [!NOTE] > If while searching you discover something genuinely missing that should be there, that is information for you beyond this request: check whether it is an isolated case or whether that document type is being lost systematically. **Can I ask the supplier to issue it now?** You can, and you must say it was issued now: a document dated today does not prove what happened then. **What if someone who has left held it?** Check their history: what they uploaded is still there; what stayed in their inbox is not. **Should I say we do not have it while still searching?** Say you are checking and when you will reply: silence is worse than any answer. ## Ejemplos **A company tells a client it does not have a three-year-old certificate.** - First checks whether its installer holds it and searches by the equipment number → It turns up in the installer's archive and is delivered in two days, without becoming a finding. **It is declared missing without searching the file.** - Searches by content before answering → Half the time it turns up and the chase is avoided. **The document exists under a different name.** - Searches by something in the content → The file name stops deciding whether it is found. **Someone else on the team has it in their inbox.** - Asks internally before saying it does not exist → You do not ask outside for what was already inside. **It genuinely does not exist and never was issued.** - Answers explaining why, and what can be provided instead → The other side knows where they stand rather than waiting. **A document belonging to another group company is requested.** - Redirects the request to whoever holds it → The request reaches somebody who can answer it. --- --- id: KB-PR-018 url: https://app.codecontract.io/help/troubleshooting/something-we-already-renewed-still-shows-expired idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-012, KB-TZ-014] citadoPor: [KB-PR-019] --- # Something we already renewed still shows expired _The new paper is there, but the alert stays red. It is almost always one of four things, and none is a bug._ **Responde a:** still shows expired after renewing · uploaded the new certificate and it stays red · the expiry date does not update · expiry alerts that will not clear You renewed the policy, the supplier sent the new certificate, someone uploaded it — and the alert is still there. Before assuming something is broken, four things are worth checking: in practice the explanation is always one of them. ## The four causes, in the order worth checking | What happened | How to spot it | What to do | | --- | --- | --- | | The new document is somewhere else | It sits loose, or in another file | Move it to where the expiring one was | | It is uploaded, but as a new document | There are two, and the old one still counts | Register it as a new version of the same | | The document's date was not updated | New paper, old date | Correct the expiry date | | The new document expires sooner than you thought | The alert is right and it surprises you | Nothing: the warning is doing you a favour | > [!IMPORTANT] > The second row is the commonest and ages worst: **uploading the new paper next to the old one replaces nothing**. Both remain, the expiry still hangs off the old one and, worse, anyone searching later may take the wrong one — because both look valid. A document that replaces another is registered as a new version of it, not as a separate document. ## How to check it in a minute 1. **Open the one raising the alert, do not hunt for the new one** — The alert hangs off a specific document: start there. 2. **See whether it has a later version** — If not, the new one is somewhere else. 3. **Check the expiry date on record** — Sometimes the paper is right and the date lagged behind. 4. **And if it all adds up, reread the new document's date** — The fourth cause is the most uncomfortable and the most useful. > [!WARNING] > A case that misleads far more than it should: **the supplier sends a certificate that is already expired or valid for a very short time**. It is issued dated months back, or covers only to the end of the quarter. The alert is not wrong — it is flagging something to raise with them before an audit does, not a system problem. ## When the alert was right **En corto** - If the new document expires soon, request the next one now: do not wait for the warning. - And if a supplier always sends right on expiry, bring the request forward by weeks. - An expiry resolved the same day it fires is one that will someday not be resolved. > [!NOTE] > If after these four checks the alert still does not add up, write to support quoting the specific document: with that reference it takes minutes to look into. **Should I delete the old document?** No: it evidences what was in force then. Replace it, do not delete it. **Can I just change the date?** Yes, if the paper is correct. If the paper is different, upload the version. **What if the warning comes too late to renew?** Widen the warning margin: it depends on how slow each supplier is. ## Ejemplos **A company uploads the renewed policy and the expiry alert stays on.** - Opens the document raising the alert and registers the new one as a version of it → The alert clears itself and there are no longer two documents that look equally valid. **The new document was uploaded without updating the date.** - Checks the document's recorded date → The warning clears as soon as the figure matches the paper. **The renewed document sits in another file.** - Attaches it to the file that raises the warning → The warning looks at the right document. **It was renewed but the supplier sent an old version.** - Checks the date on the document itself → You discover the renewal never actually arrived. **The warning refers to another document of the same type.** - Checks which specific document it points to → You renew what is missing rather than what was already there. **The validity date was misread from the document.** - Corrects the figure by checking the image → The warning becomes true again without touching the document. --- --- id: KB-PR-019 url: https://app.codecontract.io/help/troubleshooting/the-alert-reached-me-too-late idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-018, KB-TZ-014] citadoPor: [KB-PR-024] --- # The alert reached me too late _It fired when there was no time left to act. It is rarely a fault: it is a margin set by the wrong clock._ **Responde a:** the expiry alert came too late · how much notice should alerts give · I found out when it had already expired · setting the warning margin The alert fired when it was meant to, you received it, and you were still late. The normal reaction is to raise the margin at a guess; the useful one is to look at what renewing that thing depends on, because the right margin is rarely set by your calendar. ## How much notice is really needed | Who the renewal depends on | How long it takes in practice | What margin to set | | --- | --- | --- | | You | As long as you take to sit down | Little: days | | A small supplier | As long as they take to reply and issue | Weeks | | A public body or an appointment | Whatever appointment they give, not your speed | Far more than it seems | | Several parties in a chain | The sum of all, not the slowest | Double your estimate | > [!IMPORTANT] > The third row breaks the arithmetic and is never in front of you when configuring: **some renewals run on a clock neither you nor your supplier controls**. If an appointment, an inspection or an official issuance is required, the clock belongs to whoever grants it — and that can be two months out. A thirty-day margin is lavish for an insurance policy and laughable for that. Which is why margins are set per document type, not as one number for everything. ## What to look at once it has happened 1. **Check whether the alert fired and who to** — Sometimes it arrived and went to someone who was away. 2. **Measure how long the renewal actually took** — That figure, not a hunch, is next year's margin. 3. **And raise the margin only for that document type** — Raising it everywhere creates noise, and noise gets ignored. > [!WARNING] > Beware the obvious-looking fix: **a huge margin on everything makes alerts arrive so early that they get filed**. A ninety-day warning about something solved in two afternoons is read, postponed and forgotten — and when the final reminder fires nobody looks, because that document «already warned». A margin fitted to each case fires less often and is therefore read. ## The two cases where the margin is not the problem **En corto** - The alert reached one person and that person was off sick or on holiday. - Or it reached a shared mailbox nobody reads daily. - In both, the fix is not more notice: it is who receives it. > [!NOTE] > If the document belongs to a third party, warn them before your own alert fires: their clock starts when they find out, not when you do. **What margin is reasonable by default?** However long it took last time, plus a third. Better data than any rule. **Can I set two alerts, one early and one just before?** That works best: one to plan, one to act. **What if the supplier is always late?** That is a different problem, and worth raising with them, not more alerts. ## Ejemplos **A company gets fifteen days' notice on something needing an appointment two months out.** - Measures how long the last renewal took and raises the margin for that document type only → The next alert arrives while an appointment can still be booked, and nothing else gets noisier. **The warning fires with two days to go and two weeks are needed.** - Adjusts the lead time to the real renewal time → The warning arrives while action is still possible. **The deadline is calculated without allowing for the supplier.** - Adds the time the third party takes to respond → The margin includes the wait, not only the paperwork. **Warnings arrive in August and nobody reads them.** - Brings forward those falling in holiday periods → The calendar accounts for when people are around. **The warning goes to somebody who has left.** - Reviews who the warnings are addressed to → The warning reaches somebody who can act. **All warnings use the same lead time.** - Adjusts it by document type → What takes longer is warned about earlier. --- --- id: KB-PR-020 url: https://app.codecontract.io/help/troubleshooting/they-say-they-sent-it-and-you-have-no-record idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-003, KB-PR-013, KB-PR-026] citadoPor: [KB-PR-021, KB-TL-024] --- # They say they sent it and you have no record _Nearly always you are both right: they sent it and you have no record. What fails is in between._ **Responde a:** they say they sent it and i do not have it · supplier insists they sent the document · cannot find a document they claim to have uploaded · how to check whether they sent a document «I sent you that last week.» And you look, and it is not there. The conversation jams because it seems one of you must be wrong, and almost never is: they sent it, you have no record, and what failed was in transit. ## The five reasons, by frequency | What actually happened | How to spot it | What to do | | --- | --- | --- | | Sent to a person, not via the link | It is in a colleague's inbox | Search by the file name | | Replied to an old email | It arrived, but hanging off another request | Move it to the right file | | Forgot the attachment | The message is there and the file is not | Ask again, without making it a thing | | Uploaded it to another client's place | It appears nowhere of yours | Have them check who they sent it to | | It is uploaded and you cannot see it | Another name, another phase, another file | Search by date, not by name | > [!IMPORTANT] > One question settles this in a minute and almost nobody asks it: **ask for the details of the sending, not for the file again**. When they sent it, to which address or via which link, and what they saw afterwards. Those three things reveal in ten seconds which side the problem is on and end the «I sent it» / «well, it is not here» exchange, which goes nowhere precisely because both statements are true. ## How to check on your side 1. **Search by file name and by date** — Not by company name: files hardly ever carry it. 2. **Check whether it landed in another file** — Most common when that contact has several open requests. 3. **Check whether a colleague received it** — Email straight to a person is the classic hole. 4. **And if it is nowhere, say what you looked at** — «I searched by date and across the other files» stops them repeating it. > [!WARNING] > What not to do, however tempting it is to avoid an argument: **accepting an «I sent it» with no document**. If that paper supports something —an insurance policy, an authorisation, a permit— what counts on the day you are asked is the document in the file, not what was said on the phone. And that day the conversation will be nowhere to be found. Asking again is not distrust: it closes the point, and whoever really did send it takes a minute to forward it. ## What makes it stop happening **En corto** - Everything is always requested through the same place, even if you also discuss it by phone or WhatsApp. - The request link stays alive as long as people actually take to reply. - It is clear what happens after uploading: someone who sees no signal doubts, and ends up sending it elsewhere. - And files carry a recognisable name, because that is what you search by when something goes missing. > [!NOTE] > If it is the other way round —you sent something and they say they have no record— exactly the same applies in reverse: what settles it is the detail of the sending, not resending it. **Can I tell whether they opened it?** Something being sent and someone opening it are different things: do not merge them into one answer. **What if they say they sent it on WhatsApp?** Have them resend via the link: that puts the document where it will be looked for. **How long before chasing?** Whatever you stated in the first request. What does not work is never having stated it. ## Ejemplos **A supplier insists they sent their policy and it is nowhere in the file.** - Asks when they sent it and to which address, instead of asking for the file again → It turns out it went to a colleague's inbox: it is moved into the file and the request closes that day. **The supplier sent it to one person's inbox.** - Tells them to upload it through the link → The delivery is recorded where the whole team sees it. **They sent it through a channel nobody checks.** - Agrees a single channel for deliveries → Deliveries stop getting lost. **They sent it and it landed in junk.** - Checks the folder and confirms receipt → The doubt closes without accusing anyone. **They sent it to a different company in the group.** - Checks with the rest of the group before chasing → No chase goes out if the document was already inside. **They say they sent it and cannot show it.** - Asks them to upload it again through the link → Next time the delivery evidences itself. --- --- id: KB-PR-021 url: https://app.codecontract.io/help/troubleshooting/was-it-sent-or-not idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-003, KB-PR-020] citadoPor: [KB-PR-023] --- # Was it sent or not? _If it shows in the file with a timestamp, it was sent. What you do not yet know is whether it arrived, which is a different question._ **Responde a:** not sure if the email was sent · i clicked send and nothing happened · how to know if the request went out · did it get sent twice **If the send is recorded in the file with its date and time, it was sent.** That line is the answer: it does not depend on your having seen an on-screen confirmation, on your receiving a copy, or on anyone's memory. ## Three different things that get muddled | Word | What it actually means | | --- | --- | | **Sent** | It left here. The time is on record | | **Delivered** | The recipient's server accepted it | | **Opened** | Someone looked at it. Hardest to know and least important | > [!IMPORTANT] > **Do not hit send again «just in case».** It is the natural reaction and it almost always makes things worse: the recipient gets two identical emails, does not know which to act on, and if you later have to show when something was requested, you have two dates instead of one. Before resending, look at the file: the answer is there. ## If nothing shows at all 1. **Refresh the screen before anything else** — Half of all cases: it was sent and you were looking at a minute-old screen. 2. **Check the contact has an address** — A contact with no email, or a mistyped one, generates no send. 3. **And look for an error notice on the send itself** — A failure is recorded: it does not go quiet. > [!WARNING] > The most confusing case: **it was sent and no copy reached you**. That says nothing about the send — only that you were not copied. The reverse happens too: a copy reaching you does not guarantee it reached the recipient, because your own mail is the shortest path and theirs may have filters, full mailboxes or addresses that no longer exist. **Can I see the exact time?** Yes: that is what is recorded, and what counts if it has to be proven. **I sent it twice — is that a problem?** Nothing serious. Tell the recipient which one to act on. **What if the send failed?** The failure is on record. Fix the address and send again. ## Ejemplos **You hit send, see no confirmation, and send it again.** - Checks the file's record first, where the send time is logged → The duplicate is avoided, and with it the «which of the two do I act on?» conversation. **A send appears nowhere and the contact has no email address.** - Completes the contact's address and sends again → The message goes out and stops looking like a system failure. **It is resent just in case without checking the file.** - Checks whether it shows as sent, and at what time → Sending the same thing twice is avoided. **It shows as sent and the recipient does not see it.** - Checks which address it went to → The error is located without resending blind. **You want to know whether it also arrived.** - Checks the delivery status → Sent is told apart from delivered. **The send queued because of a momentary problem.** - Checks whether anything is pending dispatch → The delay is explained rather than assumed. --- --- id: KB-PR-022 url: https://app.codecontract.io/help/troubleshooting/ive-uploaded-it-is-that-it idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-005, KB-TL-003, KB-PR-014] citadoPor: [KB-PR-029, KB-PR-030] --- # I've uploaded it — is that it? _If it shows in the list with its name, it is uploaded. If data was also requested, check nothing is left unsaved._ **Responde a:** i uploaded the document and dont know if it arrived · do i need to do anything after uploading · how do i confirm the upload worked · uploaded the file can i close now **If the document shows in the list with its name, it is uploaded.** You do not also need to send an email saying you uploaded it, or wait for someone to confirm. Whoever asked can see it in their file. ## The two things worth checking before you close | What to check | Why | | --- | --- | | That the file name is the one you uploaded | It is the signal the upload finished | | That no field is left half-filled | If data was requested, uploading the file does not save it | | That no document from the list is missing | The ones still outstanding show at a glance | > [!IMPORTANT] > **Closing the window with a half-filled form saves nothing.** The file does stay uploaded —that happens on drop— but the data you were typing is lost unless you save. It is the number one cause of «I did send it» / «well, half of it is missing here». ## If something went wrong, you will notice **En corto** - A failed upload does not leave the document half-there: it is either there or not. - If it does not appear, upload it again. Repeating breaks nothing. - And if the file is large, give it time before deciding it failed. > [!WARNING] > A detail that saves grief: **uploading the wrong file is fixable, and saying so beats covering it up**. Upload the right one and tell the requester which counts. What does not work is quietly adding the good one and hoping nobody looks at the other: whoever reviews will see both and will not know which to act on. **Do I need to email to say I uploaded it?** No need. They can see it in their file. **Can I upload more than one file?** Yes, if several are requested. Each in its place. **Can I change it afterwards?** Usually yes, while the request is open. Say which one counts. ## Ejemplos **The file is uploaded, the window is closed, and the form data was half-entered.** - Saves before closing, even with fields still empty → No starting over and no second request for the missing part. **The wrong file is uploaded and the fix attempted is adding the right one on top.** - Uploads the correct one and tells the requester which counts → Whoever reviews knows which to act on instead of finding two and picking wrong. **The file shows in the list but data is still unsaved.** - Checks whether anything is pending confirmation → The delivery counts as complete when it really is. **It is uploaded and the tab closed before it finishes.** - Waits until it appears in the list → The upload is confirmed rather than assumed. **Five are uploaded and only four appear.** - Checks which is missing and uploads it again → The gap is spotted before the other side spots it. **The file name does not match what was requested.** - Checks it was uploaded in the right place → One document is not mistaken for another. --- --- id: KB-PR-023 url: https://app.codecontract.io/help/troubleshooting/did-they-get-it-did-they-open-it idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-021, KB-TL-004] citadoPor: [KB-PR-031] --- # Did they get it? Did they open it? _Two different questions, and the second matters less than it seems. What counts is whether they replied._ **Responde a:** find out if they opened my email · the supplier says it never arrived · read receipt for document requests · how do i know they saw the request **Arriving and being opened are two different things, and only the first can be known with certainty.** The second depends on things you do not control —whether their mail loads images, whether they glanced at it on a phone— so it is not worth building any decision on it. ## What is known, and how reliably | Question | How reliable the answer is | | --- | --- | | Did it leave here? | Certain: the time is on record | | Did their server accept it? | High: a rejection shows | | Did a person open it? | Low. Do not decide anything on this | | **Have they replied?** | **Certain, and the only one that matters** | > [!IMPORTANT] > **The useful question is not «did they open it?» but «have they uploaded what I asked for?».** If they have replied, when they opened it is irrelevant. And if they have not, knowing they opened it on Tuesday helps you not at all: the action is the same either way, which is to ask them again. ## When they say it never arrived 1. **Check the address, letter by letter** — By far the most common cause, and the quickest to rule out. 2. **Ask them to look in junk mail** — The second most common, and they will not look there unprompted. 3. **Resend the link and tell them by another route** — A call or a message: «I've resent the link, check your spam». > [!WARNING] > Before concluding that email is broken, check for a simpler explanation: **it may have reached the wrong person at that company**. A generic office address, a mailbox nobody watches any more, or the sales rep instead of whoever handles paperwork. Nothing is broken there — you just need to ask who to address it to, which is a one-minute conversation that saves three resends. **Is there a read receipt?** Not as a certainty. What is recorded is whether they replied. **They say it never arrived — do I resend?** Yes, but check the address first and tell them by another route. **How long before chasing?** Whatever you stated in the request. If you stated nothing, that is the real problem. ## Ejemplos **A supplier insists nothing arrived, and the address had one letter wrong.** - Checks the address letter by letter before resending → It lands first time instead of being resent three times to the same wrong place. **You spend two days watching whether the email was opened instead of calling.** - Switches the question to «have they uploaded it?» and, if not, calls → The decision is made on the reliable fact, and the time spent watching is recovered. **You keep chasing because the email does not show as opened.** - Checks whether they replied rather than whether they opened → Somebody who already delivered is not chased. **The recipient reads it in a preview pane that does not register.** - Looks at the response rather than the open → The signal watched is the one that matters. **It shows as opened but nothing has been done.** - Sends a reminder with the deadline → The nudge carries what is actually missing. **It does not show as opened and they did deliver another way.** - Checks the file before chasing → An unfair chase is avoided. --- --- id: KB-PR-024 url: https://app.codecontract.io/help/troubleshooting/i-made-a-mistake-can-it-be-undone idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-008, KB-SC-002, KB-PR-019] citadoPor: [KB-PR-025] --- # I made a mistake — can it be undone? _If it has not left your company, nearly always yes. If it went out or was sealed, it is not undone: it is corrected and flagged._ **Responde a:** how to undo a send · i deleted something by accident · can i cancel what i sent · i made a mistake what now **One rule covers everything: what has not yet left your company can be fixed; what has gone out or been sealed is not deleted — it is corrected on top, and flagged.** That tells you which case you are in before you read any further. ## The four cases | What you did | Can it be undone? | | --- | --- | | Something only you can see | Yes, straightforwardly | | A send that has not gone out yet | Yes, if you are in time | | A send that has gone out | Not deleted: cancelled or corrected, and flagged | | **Something certified or signed** | **No. That is the point of certifying it** | > [!IMPORTANT] > **The worst thing you can do is cover it up.** Rebuilding a document with an earlier date, deleting the trace of a send, or quietly sending the right one and hoping nobody looks at the other turns an ordinary mistake —the kind that happens daily— into something that looks deliberate. Correcting on top and saying so leaves a history explainable in two sentences; covering up leaves one that cannot be explained. ## The right order 1. **Stop before touching anything else** — Most big messes start with three quick fixes in a row. 2. **Check whether what you did has already left** — That is the question that decides everything else. 3. **Correct on top, without deleting the previous version** — The previous version is what explains why there is a correction. 4. **And tell whoever received it, even if they have not looked** — A two-line heads-up saves next week's entire conversation. > [!WARNING] > It helps to know in advance what is genuinely final: **certified material cannot be edited or deleted, and that is not a limitation but its reason for existing**. A seal you could redo would prove nothing. If you sealed the wrong thing, the way out is not deleting it: it is sealing the right one and recording that the first was superseded — which is exactly how any serious record gets corrected. **Can I delete a document I uploaded?** It depends whether it is already in someone else's file or certified. Check first. **What if someone else made the mistake?** Same route. What does not help is fixing it without telling them. **Is there a record that I corrected?** Yes, and you want there to be: it shows it was spotted and acted on. ## Ejemplos **A request goes out with the wrong document attached and nobody has opened it yet.** - Corrects the request and gives a two-line heads-up that the previous one is void → The recipient knows which to act on and the history explains itself. **An old version of a contract is certified by mistake.** - Certifies the correct version and records that the first was superseded → The correction holds precisely because certified material cannot be rewritten. **The error is caught before it leaves the company.** - Corrects it and sends again → The other side never sees the bad version. **The document has been sent but nobody has opened it.** - Cancels the send and sends the corrected one → The error closes before it does damage. **The document is already signed.** - Issues a correction and notifies the signers → Both versions are on record, and why. **The document has already been timestamped.** - Timestamps the correction too → Both dates exist and the history is explicable. --- --- id: KB-PR-025 url: https://app.codecontract.io/help/troubleshooting/i-sent-it-to-the-wrong-person idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-024, KB-NO-023] citadoPor: [KB-PR-008] --- # I sent it to the wrong person _Cut the access first, then tell people. In that order, and without waiting to find out whether they opened it._ **Responde a:** i sent a document to the wrong person · sent data to another client · how do i retract a misdirected send · sent to wrong recipient what do i do **First cut off access to the link, then tell people, and only at the end weigh up the scope.** That order matters: every minute the link stays live is a minute in which the wrong person can open it. ## The first ten minutes 1. **Cancel the send or the link** — Before writing to anyone. It is the only thing that shrinks the problem while it is happening. 2. **Tell whoever received it by mistake** — One sentence asking them to ignore and delete it. Most people cooperate. 3. **Send it to the right recipient** — So the work continues and does not get forgotten in the scare. 4. **And write down what happened, with times** — Ten lines today beat next month's reconstruction. > [!IMPORTANT] > **Do not wait to find out whether they opened it before acting.** It is the natural temptation —«maybe they haven't seen it and we needn't make a fuss»— and it is exactly backwards: if they have not seen it, cutting and telling costs nothing; if they have, every minute counts. Doubt is not a reason to wait, it is a reason to cut now. ## How much it matters depends on what was inside | What was sent | What else to do | | --- | --- | | A document with nothing sensitive | Cut, tell them, move on | | Personal data | Also tell whoever handles data protection | | Another client's documents | Also tell that client. They find out anyway, and worse | | Terms, prices or anything confidential | Also flag it internally before it comes back from outside | > [!WARNING] > The underlying cause is rarely carelessness: **it is two similar contacts in the address book**. Two people with the same name at different companies, the same company entered twice, or a generic office address sitting next to the individual's. Once the fire is out, half an hour cleaning up those duplicates is worth more than any resolution to be more careful. **Do I tell them even if they never reply?** Yes. The notice puts you in a different position even with no answer. **Do I have to report it internally?** If it held personal data or a third party's, yes, and quickly. **Can I find out whether they opened it?** Not with certainty, and it does not change what to do now. ## Ejemplos **A file is sent to another client's contact with a similar name.** - Cancels the link first, tells them after, and resends to the right person → The window in which someone could open it shrinks to minutes. **After the scare, the address book still holds the two near-identical contacts.** - Spends half an hour merging duplicates and disambiguating the names → The cause disappears, not just the episode. **A file is sent to the wrong contact.** - Revokes access before writing to anyone → Exposure is cut even if the other side never looked. **The wrong recipient belongs to another company.** - Cuts access and alerts the right people internally → Whoever should decide what to communicate does. **It is discovered hours later.** - Cuts access anyway and records what was sent and to whom → The scope is documented for whatever follows. **The recipient is simply asked to delete it.** - Revokes access as well as asking → You do not depend on a third party complying. --- --- id: KB-PR-026 url: https://app.codecontract.io/help/troubleshooting/i-cant-find-where-to-do-it idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-011, KB-ET-012] citadoPor: [KB-PR-020] --- # I can't find where to do it _Before hunting further, check whether you simply cannot do it. What is not yours to do does not appear — and that is not a bug._ **Responde a:** cant find the option · where is the button for this · the option in the guide doesnt appear for me · i cant do something i could before **If an option is not there, the likeliest explanation is not that it is hidden: it is that your permissions do not include it.** What is not yours to do is not greyed out, it is simply absent — which is why people spend twenty minutes hunting for something that was never going to be there. ## The three reasons, by frequency | Reason | How to confirm | | --- | --- | | You do not have permission | Ask whoever administers your organisation | | You are in the wrong place | The action lives where the thing lives: on the document, not the list | | The current state does not allow it yet | Some things can only be done when their moment comes | > [!IMPORTANT] > **Ask before the twenty minutes, not after.** It is a thirty-second question for whoever administers your organisation and it says nothing bad about you: permissions were set by someone else, sometimes years ago, and often were not even a considered decision. Searching longer does not change the permission. ## If you could before and cannot now **En corto** - Someone changed permissions, usually without meaning to affect you. - Or you signed in with a different account from your usual one. - Or you are in another organisation, if you work across several. > [!WARNING] > A silly check that solves more cases than you would think: **look at which account you signed in with**. Having two —your work one and a personal one you were once invited with— is commoner than it sounds, and it explains at a stroke why «none of my stuff is here»: nothing is missing, you are looking somewhere else. **Who do I ask?** Whoever administers your organisation. Usually the person who set you up. **Can I ask to be given permission?** Yes, and say what for: it gets granted faster when it is understood. **I signed in and see none of my things** Check the account and the organisation before anything else. ## Ejemplos **Someone spends twenty minutes hunting an option their permissions do not include.** - Asks whoever administers the organisation as soon as it is not found first time → It is settled in thirty seconds with a permission or a «someone else does that». **A user signs in and sees none of their files.** - Checks which account they signed in with and which organisation they are in → Everything appears: they were looking from the account they were once invited with. **An option belonging to another role is looked for.** - Checks what permissions their account has → It becomes clear why it is absent instead of searching on. **The action only exists in a certain file status.** - Checks what status it is in → You know what is needed for it to appear. **The search happens in the wrong menu.** - Uses the search box instead of walking the menus → You reach what you need in one step. **The option moved in a recent version.** - Checks where it is now → The change stops looking like a disappearance. --- --- id: KB-PR-027 url: https://app.codecontract.io/help/troubleshooting/the-link-doesnt-work-for-me idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-013, KB-TL-021, KB-PR-004] citadoPor: [KB-TL-025] --- # The link doesn't work for me _Ask whoever sent it for a new one. It is not your fault and it takes them a minute to fix._ **Responde a:** the link has expired · the link they sent wont open · i get an error opening the link · cant access the document link **Write to whoever sent it and ask for a new one.** It is the fastest route, takes them a minute, and says nothing bad about you: links expire on purpose, precisely so an old one is not left open out there. ## Before writing, two thirty-second checks 1. **Open it in another browser or on your phone** — Rules out half the odd cases without bothering anyone. 2. **Check you copied the whole link** — Forwarding between colleagues cuts it in half surprisingly often. 3. **And look for a more recent email** — If a new one was already sent, the old one stops working. > [!IMPORTANT] > **If the link expired, what is inside is not lost and you do not start over.** The file is where it was and whatever you already uploaded is still uploaded: all that is needed is a new door. Many people assume they will have to redo the whole thing and stop replying out of weariness — and that is what genuinely delays matters. ## What to say so they answer first time **En corto** - That the link will not open, and since when you have been trying. - Which request it is: the company and what was being asked for. - And which address you want the new one sent to, if not the same one. > [!WARNING] > A confusing case: **the link belongs to a colleague and will not work for you**. If the email was forwarded from someone else at your company, the door may be in their name. It is not a fault — the request was addressed to a specific person. The way out is to ask for one in your name, and to say who handles this from now on. **Have I lost what I already uploaded?** No. It is where it was; you just need a new link. **Can I use a colleague's link?** Sometimes it will not work. Better to ask for one in your name. **How long do links last?** It depends on the sender. If yours expire often, tell them: it can be extended. ## Ejemplos **The link expires midway through gathering the paperwork and the whole thing is given up on.** - Asks for a new one, explaining which request it is → What was already uploaded is still there and they carry on from where they stopped. **A colleague forwards their email and the link will not open on another computer.** - Asks for the request to be sent in their name and says who handles it from now on → Access is fixed and the right recipient is set up for next time. **The link was copied incompletely from the email.** - Asks for it to be resent → It is resolved without depending on copying correctly. **The link was opened on one device and is tried on another.** - Opens it from the same mailbox it arrived in → Access works because it is issued to whoever received it. **A long time has passed since it arrived.** - Asks whoever sent it for a new one → The new link takes a minute to arrive. **The link was forwarded by a colleague.** - Asks for it to be sent directly → Each delivery stands in the name of whoever makes it. --- --- id: KB-PR-028 url: https://app.codecontract.io/help/troubleshooting/what-happens-if-i-dont-send-it idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-022, KB-TL-025, KB-PR-031] citadoPor: [KB-NO-027, KB-PS-023] --- # What happens if I don't send it? _It depends what they need it for, and you find that out by asking. What never helps is not replying._ **Responde a:** what happens if i dont send the paperwork · am i obliged to send what they ask · can i refuse to provide a document · consequences of not providing documents **It depends why they are asking, and that is the question worth putting.** A requirement for invoicing you, one for entering a site, and an internal collection exercise of theirs are three very different things. ## The four reasons, and what tends to be at stake | Why they ask | What tends to happen if it is missing | | --- | --- | | It is a condition of working together | Onboarding, the order or site access stops | | A third party requires it of them | Their problem becomes yours, with a deadline | | Their own internal control asks for it | Persistence, and little more short-term | | Nobody quite knows why | Commoner than it looks. Ask | > [!IMPORTANT] > **What makes all four rows worse equally is silence.** «I don't have it», «I can't give you that», «I'll have it in two weeks» and «what do you need it for?» are four answers that unblock; not replying unblocks none of them. And contrary to what many fear, saying you cannot rarely breaks a commercial relationship — what wears it down is having to chase you. ## How to answer when the answer is awkward 1. **Say which part you can provide** — There is nearly always a reduced version that meets the need. 2. **Say when, if it is a matter of time** — A specific date is worth more than a long apology. 3. **And ask whether something else would do** — Many document lists are copied from elsewhere and accept equivalents. > [!WARNING] > Before writing something off as impossible, check one thing: **what they want may exist under another name**. A good share of «I don't have it» is really «I don't have it under that name» — the same paper is issued by a different body, or your sector calls it something else. Describing what you do hold and asking whether it works solves more cases than hunting for exactly what the list says. **Am I obliged to provide it?** It depends on your contract and the relationship. Ask what they need it for. **What if they ask for something that does not exist in my case?** Say so. It is useful information and usually gets it dropped. **Can I give only part of it?** Often yes, and it is usually the good way out. Propose it yourself. ## Ejemplos **You are asked for a document you do not have and stop replying rather than say no.** - Says which part they can provide and by when the rest would exist → The relationship holds and the request is adjusted to what actually exists. **A document on the list does not exist under that name in your sector.** - Describes the one they do hold and asks whether it works as an equivalent → The list gets corrected instead of leaving a permanent gap. **Nothing is answered and the other side keeps waiting.** - Answers, even if only to say it is not possible → The other side can decide instead of waiting. **It is assumed nothing happens without that paper.** - Asks what they need it for → The decision is taken knowing what is at stake. **The document does not exist and nobody says so.** - Explains why it does not exist and proposes an alternative → The conversation moves instead of stalling. **It takes longer than asked and no notice is given.** - Gives notice before the deadline with a new date → The other side reorganises in time. --- --- id: KB-PR-029 url: https://app.codecontract.io/help/troubleshooting/can-i-see-what-i-already-sent-you idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PR-022, KB-TL-023, KB-PR-030] citadoPor: [KB-TL-026] --- # Can I see what I already sent you? _While the link is live, usually yes. And if not, ask: it is what stops you sending the same thing twice._ **Responde a:** can i see the documents i uploaded · i want to check i sent the right thing · how do i review what i already sent · i dont remember which documents i sent **If the link you uploaded through is still live, go back in: what you sent is there.** And if it has expired, ask whoever requested it to tell you what is on record — it is a normal question and takes a minute to answer. ## Why it is worth looking **En corto** - So you do not send the same thing twice, which causes duplicate reviews. - To check you uploaded the right file and not the draft sitting next to it. - To know what is still missing without having to ask. - And to be clear which of your information is in whose hands. > [!IMPORTANT] > **What is worth avoiding is trusting memory after a few weeks.** «I think I already sent that» is the starting point of half of all documentary tangles: it gets assumed, never checked, and the document either never arrived or landed in another file. Looking takes a minute and lets you talk with facts rather than impressions. ## If the link no longer works 1. **Ask what is recorded as received, and when** — That is what you need: the list, not the files again. 2. **And keep that answer** — It saves you the same question in six months. 3. **If something is not on record, send it without arguing** — A minute's upload against several emails of discussion. > [!WARNING] > One habit removes all of this at a stroke: **keep your own copy of what you send, in your own files**. Not because the other side will lose it, but because the one who needs to know what was sent, when and to whom is you — and that question always arrives at the worst moment, usually once the relationship with that company has cooled. **Can I download what I uploaded?** It depends how the request is set up. Ask. **What if I uploaded the wrong file?** Upload the right one and say which counts. It is routine. **Can they see when I uploaded it?** Yes, it is recorded with its date. That protects both sides. ## Ejemplos **A supplier believes they sent the insurance and actually uploaded last year's.** - Goes back in through the link and checks which file is on record → The mistake shows before it gets rejected and is fixed the same day. **Six months later you cannot remember what paperwork you gave that client.** - Keeps their own copy of what they send, in their own files → The question gets answered without depending on the other side replying. **The same thing is sent again just in case.** - Checks first what is recorded as delivered → Duplication and version confusion are avoided. **The link is no longer valid and there is doubt.** - Asks whoever sent it for the delivery status → The answer arrives without uploading anything again. **You want to keep a copy of what was sent.** - Downloads or keeps a copy at the moment of delivery → Your own record does not depend on someone else's. **Nobody remembers which version was sent.** - Checks the date of what was delivered → You know which version the other party holds. --- --- id: KB-PR-030 url: https://app.codecontract.io/help/troubleshooting/my-document-was-rejected idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-022, KB-PR-022] citadoPor: [KB-PR-029] --- # My document was rejected _Read the reason before uploading anything again: half of all rejections are fixed by the same document, better scanned._ **Responde a:** my paperwork was rejected · why is my document being rejected · what to do if they dont accept what i uploaded · rejected document how to fix **Start with the reason, not with hunting for another document.** A rejection nearly always comes with a short reason, and that reason decides whether you need something different or simply to send the same thing another way. ## The four reasons, and what to do with each | Reason | What to do | | --- | --- | | It cannot be read | The same document, better scanned. The commonest | | It has expired | Get the current one. If it takes time, say when you will have it | | It is not the document they wanted | Ask which one before sending another | | Something is missing (a signature, a stamp, a page) | Have it completed at source, do not assemble it yourself | > [!IMPORTANT] > **A rejection is not a complaint about you.** Whoever reviews usually works from a checklist and flags what does not fit; they are not judging your company or annoyed that you sent it. Treating it as what it is —another step in the process— avoids the two reactions that drag it out: taking offence, or parking it out of awkwardness. ## If the reason is not clear 1. **Ask what exactly is missing** — «Rejected» with no reason is a badly closed request, not a mystery of yours. 2. **Say what you sent and what else you hold** — The way out is often a document you already have and they did not know about. 3. **And confirm before uploading again** — A minute confirming beats a second rejection. > [!WARNING] > The most infuriating case and the easiest to avoid: **rejected because the photo is skewed, dark or has a finger across it**. There is nothing wrong with the document, only with how it arrived. If you are photographing it, do it with the paper flat, light in front, and check the corners and dates are legible before uploading. It is the number one reason for rejection and it is fixed on the spot, not by obtaining anything new. **Do I have to start over?** Almost never. In half the cases the same document, better sent, works. **It was rejected with no reason given** Ask. With no reason, the request is badly closed. **Can I send several just in case?** That delays things most: whoever reviews has to decide which counts. ## Ejemplos **A certificate is rejected because the photo is dark and skewed.** - Re-photographs it with the paper flat and light in front, checking the corners → The same document is accepted first time, with nothing new obtained. **A rejection arrives with no reason and the document is parked for two weeks.** - Asks what exactly is missing and says what other documents they hold → It emerges that one they already had would do, and the request closes that day. **The same thing is uploaded again without reading the reason.** - Reads the reason before touching anything → Half the rejections are fixed with the same document. **The rejection is about scan quality.** - Retakes the capture with better light and framing → It is accepted second time without asking the issuer for anything. **The document has expired.** - Requests the renewal instead of resending → The real problem is solved rather than the symptom. **A page of the document is missing.** - Uploads the complete document → The rejection does not repeat for the same reason. --- --- id: KB-PR-031 url: https://app.codecontract.io/help/troubleshooting/were-asked-for-papers-and-were-not-their-supplier idioma: en categoria: problemas audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-025, KB-TL-021, KB-PR-023] citadoPor: [KB-PR-028] --- # We're asked for papers and we're not their supplier _Reply that it is not yours. One line, and it stops someone waiting for something that will never arrive._ **Responde a:** asked for documents belonging to another company · request addressed to the wrong company · mistaken for another supplier · no relationship with whoever is asking **Reply with one line saying it is not yours and leave it there.** No need to investigate where it came from or to apologise: the sender needs to know in order to fix it, and until they do they will keep waiting. ## The three reasons it reached you | What happened | What to say | | --- | --- | | Similar names got confused | «We are not that company» and, if you know, which one is | | You worked with them years ago | «We have had no relationship since X» | | Someone mis-copied a detail from a list | «This is not ours». That is enough | > [!IMPORTANT] > **Even if it is not yours, if the message carries another company's information it is worth saying so.** A list with details that are not yours, an attachment belonging to a third party: that is a mistake they will want to hear about before anyone else does. Saying so costs the same single line and leaves you in a very good light — and saves someone a problem considerably worse than yours. ## What not to do **En corto** - Ignore it: reminders will keep coming and someone will keep waiting. - Reply angrily: it is nearly always a mis-copied detail, not carelessness aimed at you. - And certainly do not send your own documentation «in case it helps». > [!WARNING] > Before writing it off as an error, check one thing: **it may be yours and you not know it**. A client who knows you under another trading name, a site you entered as a subcontractor's subcontractor, an order handled by someone else at your company. A two-minute internal call before replying «that is not us» avoids the awkward case of denying a relationship that does exist. **Do I have to reply if it is not for me?** You are not obliged, but one line closes the matter for everyone. **What if they insist afterwards?** Repeat it once in writing. That makes it clear and documented. **They sent me another company's data** Tell them. It is a mistake they will want to know about at once. ## Ejemplos **A request arrives addressed to a company with a name similar to yours.** - Replies with one line saying it is not theirs → The requester corrects the recipient and stops waiting for something that was never coming. **The message has an attached list containing another company's details.** - Warns them that information not meant for them has arrived → The error is stopped before that list travels any further. **A request arrives from an unknown company.** - Replies that it does not apply, in writing → Nobody keeps waiting for something that will not come. **It is ignored in case it is important.** - Answers in one line clarifying the situation → The sender fixes their list instead of chasing. **The request is addressed to a similarly named company.** - Says so when replying → The sender finds who they were actually looking for. **You were their supplier years ago and no longer are.** - Explains since when there has been no relationship → The other side's list gets updated. --- --- id: KB-GL-015 url: https://app.codecontract.io/help/glossary/words-that-get-confused idioma: en categoria: glosario audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-001, KB-GL-005] citadoPor: [KB-GL-003] --- # Words that get confused _Pairs of terms that look alike and are not, with the difference that matters._ **Responde a:** difference between signing and certifying · validating or verifying a document · are approving and accepting the same · difference between a file and a folder Many misunderstandings with suppliers, clients and auditors come from using as synonyms words that mean different things. These are the ones that cause the most confusion. **Signing and certifying** — Signing expresses a will about a content: I accept it, approve it, acknowledge it. Certifying fixes that a file existed and has not changed since a date. You can certify something nobody signs, and sign something without certifying it. **Verifying and validating** — Verifying checks that something is what it claims to be (the file has not changed, the signature is genuine). Validating decides that it serves your purpose. A certificate can verify perfectly and be useless to you because it has expired. **Approving and accepting** — Accepting is receiving something as delivered. Approving is signing off on its content. When a process mixes them, someone ends up endorsing what they had merely received. > [!IMPORTANT] > The pair that causes most trouble is the second. "It is verified" and "it is validated" sound alike and mean different things in an audit: the first is a technical property of the file, the second is your decision, which you answer for. ## Three more, more briefly | Pair | Difference in one line | | --- | --- | | Document and data | The document is the file; the data is what was extracted from it | | File and folder | A file has status and process; a folder only groups | | Expired and superseded | Expired is stated by its date; superseded is decided by you | > [!WARNING] > And one that is not a pair but a trap: "certified copy" does not mean the same in every context. When someone asks for one, ask exactly what they need before sending anything — often a verifiable document is enough. ## Why it is worth using them properly **En corto** - With an auditor, the right word avoids an extra request. - With a supplier, it avoids them delivering something else. - And within the team, it stops someone approving what they only had to receive. > [!NOTE] > If one of these words is used differently in your company, write that down. That your sector says "validate" for what here is "verify" is not a problem as long as it is clear somewhere. **Does it matter day to day?** Usually not. It stops not mattering as soon as there is a third party or a dispute. **What is the commonest mistake?** Using "validated" to mean the file is intact. **Are there more terms?** Yes, in the general glossary and in each concept's own entry. ## Ejemplos **A client asks for "validated documentation" and the supplier sends verifiable files.** - They ask what exactly is needed - It turns out they wanted quality sign-off, not a file property → The right thing is delivered first time instead of two rounds of emails. **An «original» document is requested and a scan arrives.** - Clarifies whether paper is needed or a copy suffices → A whole courier round trip is avoided. **Signing is confused with giving approval.** - Distinguishes who approves from who signs → The circuit reflects what actually happens. **«Current» and «valid» are used interchangeably.** - Checks what each one refers to → You ask for the date or the check, as appropriate. **A client asks for «traceability» and expects a report.** - Asks what they want to be able to demonstrate → What is delivered addresses their actual need. **«Expired» is mixed up with «never provided».** - Distinguishes what lapsed from what never arrived → The chase is aimed at the right thing. --- --- id: KB-GL-016 url: https://app.codecontract.io/help/glossary/what-is-an-extracted-value idioma: en categoria: glosario subcategoria: documentos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-010, KB-DI-016] citadoPor: [KB-GL-020] --- # What is an extracted value _The difference between the document and what was pulled out of it, and why they are not worth the same._ **Responde a:** what is an extracted value · difference between document and data · ai extracted fields · why does the value not match the pdf **Extracted value** — A specific value — a date, an amount, a batch number — read from inside a document and stored alongside it, without replacing it, so it can be searched, compared and used for alerts. It is the most misunderstood piece of the system, and the confusion has practical consequences: many people assume that if the value is wrong the document is wrong, or that if the value is right there is no need to look at the document. Both are false. ## What each one is | Aspect | The document | The extracted value | | --- | --- | --- | | What it is | The original file exactly as it arrived | A value read from it | | What it is for | It is the evidence | It is what enables search and alerts | | If they disagree | The document wins | The value gets corrected | | Can it be corrected | No, it is what it is | Yes, and there is a record of who did it | > [!IMPORTANT] > The third row is the rule that settles almost every doubt: **on any discrepancy, the document wins**. The value exists so you can find and control things; the evidence is still the file. That is why correcting a misread value is not "falsifying" anything — you are adjusting the index, not the original. ## What having them is for **En corto** - Searching inside: finding a delivery note by its number without opening a hundred. - Alerting: if the expiry date is extracted, the warning can exist. - Comparing: cross-checking what two documents on the same matter say. - And counting: producing a report without opening documents one by one. > [!WARNING] > The nuance you cannot deduce: a document **with no extracted values is still there and still works as evidence**. All it loses is being searchable by content and being able to warn about its dates. It is the difference between an archive that stores and one that also works — and it explains why an unread scan feels "absent" even though it displays perfectly. ## When to check by hand 1. **If it feeds an invoice or a mandatory record** — Any figure going outward gets checked against the image. 2. **If the document was handwritten or corrected** — There, reading returns plausible values that may not be the written ones. 3. **And if the value decides something** — An expiry that triggers a block deserves thirty seconds of checking. > [!NOTE] > Each AI reading of a document is an action and consumes; consulting the extracted value afterwards as often as you like does not. Hence deciding which fields matter per document type instead of extracting everything from everything. **Can I add a value that is not in the document?** You can note it, but it should be distinguishable from what was read: they are not the same. **Does correcting the value change the document?** No. The document is never touched. **What if the document is replaced by a new version?** Values are re-read from the new version; the previous one keeps its own. ## Ejemplos **Someone sees the extracted date does not match the PDF and assumes the document is wrong.** - Checks the image and corrects the value, which was what was off → The expiry alert is right again and the document remains intact as evidence. **A figure is corrected and people think the document changes.** - Checks the document is unchanged → The evidence stays intact even as the figure is adjusted. **A search by amount does not return the document.** - Checks whether that field was extracted → You know whether the figure is missing or the document is. **Two different documents give the same figure.** - Looks at which one each came from → You can reach the source from the figure itself. **An extracted figure is used in a report without review.** - Approves first whatever was flagged as uncertain → The report rests on checked data. **Somebody edits a figure and nobody knows it changed.** - Checks the figure's history → The correction has an author and a date. --- --- id: KB-GL-017 url: https://app.codecontract.io/help/glossary/controller-and-processor idioma: en categoria: glosario subcategoria: cumplimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-013, KB-GL-014] citadoPor: [KB-GL-020] --- # Controller and processor _Two words used as synonyms that mean very different things: one decides, the other executes._ **Responde a:** difference between controller and processor · who is the data controller if I use a platform · what is a data processor · is the provider responsible for my data These are the two figures the whole of data protection law rests on, and in everyday conversation they are used interchangeably. The difference is not about size or importance: it is about who makes the decision. **Controller** — Whoever decides what data is collected, what for and for how long. Normally, your company. **Processor** — Whoever handles that data following your instructions, because you hired them to. Normally, the tool's provider. ## What falls to each of them | Decision | Who makes it | What it means in practice | | --- | --- | --- | | What data is asked of a supplier | You | Asking for too much is also a decision | | What it is used for | You | Using it for something else later is not automatic | | How long it is kept | You | The tool keeps what you tell it, for as long as you tell it | | How it is protected technically | The provider | Encryption, access, backups, isolation between clients | | Who can get inside your account | You | Permissions are given and taken away by you | > [!IMPORTANT] > The costliest mistake is assuming that **hiring a good tool transfers the responsibility**. It does not. The provider answers for protecting what you entrust to it and for doing only what you ask; deciding what is kept, what for and until when remains yours, and it is exactly what gets checked when somebody asks. ## What is worth demanding from a provider **En corto** - A contract describing what it handles, what for and with what safeguards. - Knowing which countries it is stored in and who can access it. - And which other providers it relies on, because its chain affects you too. > [!WARNING] > That last point surprises people: **a processor usually relies on other processors** — hosting, email, messaging. That is not irregular, but you are entitled to know about it, and you are the one who will be asked, not them. When a large client sends its questionnaire, the question lands at your door. In practice this turns into one very concrete decision when setting up any tool: do not switch on fields «just in case». Every field you ask for is data you must justify, safeguard and eventually delete. > [!NOTE] > How this translates into specific documents, contracts and deadlines depends on your case and the framework that applies to you — the **GDPR** for anyone operating in Europe, among others. **Your adviser settles that**; here we only explain who is who so the conversation starts on the right foot. **If the provider suffers an incident, am I liable?** Each side answers for its own part, which is why it matters to have written down who owed what. **Can I ask them to delete everything?** Yes: they work on your instructions, and that includes the end of the relationship. **What if two companies decide together?** That figure exists and changes the obligations; it is a conversation for your adviser. ## Ejemplos **A client asks a company who handles its data and under what safeguards.** - Answers with its own collection and retention criteria, attaching what the provider supplies → The answer comes from whoever decides, which is who owed it. **A client asks how long their data is kept.** - Answers with their own retention policy → Whoever decides answers, not whoever executes. **A question that belongs to the company is passed to the provider.** - Distinguishes what each party decides → The answer comes from whoever can give it. **A provider's safeguards must be evidenced to a client.** - Attaches the documentation the provider supplies → The provider's material is supplied without assuming their role. **A contract is signed without defining who decides what.** - Clarifies it with the adviser before signing → The split is written down before it is needed. **A third party asks the provider for data directly.** - The request is redirected to whoever decides → The decision chain is respected. --- --- id: KB-GL-018 url: https://app.codecontract.io/help/glossary/what-is-a-participant idioma: en categoria: glosario subcategoria: procesos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-011, KB-GL-012] citadoPor: [KB-TL-007] --- # What a participant is _Who takes part in a file, and why their name stays there even after they stop working with you._ **Responde a:** what is a participant in a file · who takes part in a process · can someone take part without an account · remove someone from a file A file is almost never one person's business. There is whoever opens it, whoever contributes a document, whoever reviews it and whoever closes it — and often someone on the outside who does not work with you and has no reason to hold an account. **Participant** — Anyone who takes part in a file: contributing something, reviewing, approving or simply receiving what is asked of them. ## The three types worth telling apart | Type | Who they are | What they need to take part | | --- | --- | --- | | Internal | Someone on your team | Their user and the permissions you granted | | External | A supplier, a client, a technician | Nothing beyond the link sent to them | | Automatic | A task that runs on its own: a reminder, a check | Someone to have set it up | > [!WARNING] > What surprises people most about the second type: **an external participant needs no account to leave a trace**. When they upload a document through the link you sent, who they were, when they did it and what they contributed is recorded, just as for someone in-house. You do not have to give them access to your account to have evidence of what they did — and you are better off not doing so. ## What happens when someone stops taking part 1. **They are removed from whatever is open** — They stop receiving notices and can no longer contribute. 2. **What they already did stays** — Their name remains on every step they took, with its date. 3. **And someone else takes their place** — The file carries on; what changes is who answers from now on. > [!IMPORTANT] > That second point is deliberate and sometimes uncomfortable: **removing someone from a process does not erase what they did**. If it did, the file would stop telling what actually happened, which is precisely what it is for. A history rewritten whenever someone leaves proves nothing. The practical consequence is simple: each person should take part under their own name, not through a shared department account. A history full of «admin» says nothing about who did what on the day you need to find out. > [!NOTE] > A person's rights over their own personal data are a different matter, and they are honoured. Traceability of who did what inside a file is one thing; that person's personal data is another. **How the two are reconciled in your case is for your adviser to settle**. **Does an external participant see the whole file?** No: they see what is asked of them and what is shared with them, not the rest. **Can I add someone halfway through a process?** Yes, and the date they joined is recorded. **What if the same person takes part for two different companies?** They are told apart by the role they hold in each file. ## Ejemplos **An external technician has to add a certificate to an ongoing file.** - Gets a specific link instead of an account user → They contribute their part, who and when is recorded, and they get into nothing else. **A participant leaves the company and there is a wish to remove their name from the file.** - Keeps the record of what they did → The history stays true. **Someone who only had to provide one paper is invited as a user.** - Sends them a participant link instead → No licence is consumed for a one-off contribution. **Two people from the same company provide different documents.** - Records each as a participant → It is on record who provided what. **A participant asks to see the whole file.** - Checks what they are entitled to see → They see their part without reaching everyone else's. **Months later it must be established who provided a certificate.** - Checks the participant record → The question is answered without phoning anyone. --- --- id: KB-GL-019 url: https://app.codecontract.io/help/glossary/what-a-template-is idioma: en categoria: glosario subcategoria: procesos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-011, KB-TL-018] citadoPor: [KB-TL-007] --- # What a template is _The mould files are opened from. And the key part: changing the mould does not change what is already open._ **Responde a:** what is a process template · difference between template and file · does changing the template affect open files · deleting a template already used A template is the written answer to «what do we always ask for in this case». It is defined once — which documents, in what order, from whom and with what deadlines — and from then on each real case opens from it without rethinking anything. **Template** — The definition of a process: what is requested, in which phases and under what conditions. It holds no documents and no specific people. **File** — A real case opened from a template, with its supplier, its dates and its documents. ## What lives where | Element | In the template | In the file | | --- | --- | --- | | What is requested | Yes, defined | Copied when it opens | | From whom | No: only the role played | Yes: the specific person or company | | Documents | Never | Whatever has been contributed | | Dates | Deadlines, in the abstract | The real dates | > [!IMPORTANT] > The point to be clear on before touching anything: **changing the template does not change files already under way**. What is in progress followed the mould in place the day it opened, and keeps it until it closes. This is not an oversight: if it changed, a half-completed file could suddenly demand a document nobody ever asked that company for, and its history would stop explaining what happened. Changes apply to whatever opens from now on. ## What follows from that **En corto** - You can fix a template without fear of breaking what is in progress. - And if the change is urgent for something already open, add it in that file, not in the mould. - Files opened under different versions will coexist, and that is normal. - Which is why a template's name should say what it is, not when it was made. > [!WARNING] > On retiring a template already in use: **files opened from it do not vanish or lose their content**. What was requested, who contributed it and when lives in the file itself, not in the mould. What you do lose is the ability to open new cases the same way — so have the replacement ready before retiring it, not after. ## When to make a new one and when to tweak 1. **Tweak: a deadline changes, a wording, one more document** — The normal case, and it breaks nothing. 2. **New: the process is genuinely another** — If the phases and the people asked change, it is not the same one. 3. **And if in doubt, look at the reports** — Two different things under one name mix the numbers forever. > [!NOTE] > A well-thought-out template is the part of all this that saves the most, and also the most improvised. The time spent on it once comes back with every file opened afterwards. **Can I copy a template and adjust it?** Yes, and that is standard when a client wants something different. **How many should we keep?** As many as someone can explain. Twenty near-identical ones maintain themselves badly. **Do templates appear in reports?** What is counted are the files; the template is how they group. ## Ejemplos **A company fixes a deadline in its supplier onboarding template with twelve onboardings running.** - Changes the template and adds the urgent item by hand in the two files that need it → Running onboardings keep the rules they were given and new ones come out right. **A template is corrected and people expect what is already open to change.** - Adjusts by hand the in-flight files that need it → What was communicated to each supplier stays true. **Each person creates their own template for the same thing.** - Keeps one and shares it → Improvements benefit everyone rather than one person. **A template accumulates documents nobody requests any more.** - Reviews it periodically → You stop asking for what nobody looks at. **A variant is needed for one type of supplier.** - Creates a second template with a clear name → The original is not twisted to cover cases it does not. **Nobody knows which template to use for a new case.** - Names templates after the case they solve → The choice is obvious without asking. --- --- id: KB-GL-020 url: https://app.codecontract.io/help/glossary/what-a-batch-is idioma: en categoria: glosario subcategoria: documentos audiencia: usuario nivel: basico actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-016, KB-AL-013, KB-GL-009, KB-GL-017] citadoPor: [KB-AL-016, KB-AL-017, KB-AL-018, KB-AL-024] --- # What a batch is _Not a quantity or a date: a set of things sharing one history. And that decides how far a problem reaches._ **Responde a:** what is a production batch · difference between batch and consignment · what the batch number is for · how a batch is defined It is one of the most used and least defined words. It shows up on a label, on a delivery note and in an alert, and it is nearly always understood as «what was made that day» — which sometimes matches and sometimes does not. **Batch** — A set of units sharing the same conditions: same origin, same process and same period. It is given a code so it can be referred to later. ## What it is actually for | Situation | What the batch makes possible | | --- | --- | | A client reports a problem | Knowing what else went out under the same conditions | | A supplier flags an incident | Knowing whether it affected you and by how much | | Product has to be withdrawn | Withdrawing only what is needed, not the whole month | | Someone asks about an old shipment | Going back to the conditions of that moment | > [!IMPORTANT] > From which comes the only rule that matters when defining one: **you decide the batch, and the bigger it is, the more gets withdrawn when something fails**. Group a whole month's production under one code and a problem in one unit affects the whole month — and you will not be able to show otherwise, because nothing distinguishes one unit from another. A small batch costs a little more recording and saves enormous withdrawals. ## What breaks a batch unnoticed **En corto** - Topping up a tank or silo without closing the previous one: from then on there are two. - Swapping an ingredient or a component mid-run. - Relabelling or repacking without carrying the original code across. - And noting the batch «at the end of the day», once it has all been mixed. > [!WARNING] > A frequent confusion worth undoing: **your supplier's batch and yours are not the same, and both are needed**. Theirs identifies what they delivered; yours, what left your hands. Keep only one and you can look one way but not the other — and half the time the question arrives from precisely the missing side. ## How to choose a code 1. **Unique, and not repeated next year** — Codes that reset annually are a guaranteed problem. 2. **Readable on the label and typeable without hesitation** — Someone will read it out over the phone one day. 3. **And no decoding needed to know what it belongs to** — A code only its designer understands is useless in an emergency. > [!NOTE] > In some sectors how a batch is defined and identified is regulated. **What yours requires is for your adviser or quality manager to confirm**; here we explain what it is for, which is what should shape the definition. **Are batch and consignment the same?** In practice they are used almost alike; what matters is that they are identified. **Can I change how I define batches?** Yes, marking from when: earlier ones are still read under the old rule. **What if a product has no batch?** Then what can be traced is the shipment: less precise, better than nothing. ## Ejemplos **A company groups a whole month's output under one code and a problem appears in one unit.** - Defines batches per run and records the code at the start, not the end → The next incident is contained to a few hours of production instead of a whole month. **The batch code is recorded at the end rather than the start.** - Records the batch at the moment of production → The data is exact rather than reconstructed. **A batch groups things that do not share a history.** - Defines the batch by what they genuinely share → Containing a problem stops dragging in what is unaffected. **Nobody knows what went into a specific batch.** - Ties raw materials to the output batch → Tracing runs backwards, not only forwards. **The batch does not travel through to the customer's delivery note.** - Carries the code through to the outgoing document → You can tell which customer received which batch. **The batch is defined with production in mind rather than an incident.** - Chooses the width by how much would have to be recalled → The decision is taken with the scenario that matters in view. --- --- id: KB-GL-003 url: https://app.codecontract.io/help/glossary/what-is-an-electronic-signature idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-009, KB-GL-004, KB-GL-015] citadoPor: [KB-GL-004] --- # What is an electronic signature _Accepting a document electronically while leaving proof of who, what and when._ **Responde a:** what is an electronic signature · digital signature definition · difference between electronic and digital signature · is signing electronically the same as by hand **Electronic signature** — The act of accepting a document by electronic means, together with the set of data that later proves who accepted it, which exact document it was, and when. What matters is not the squiggle or the image: it is the evidence left behind. A scanned signature pasted into a PDF looks like a signature and proves almost nothing; an electronic signature with no drawing at all can prove a great deal more. ## What makes it hold **En corto** - That you can prove who signed. - That you can prove which document they signed, exactly that one. - That the time is set by someone other than the signer. ## Electronic and digital signature In conversation they are used interchangeably. Strictly, "digital signature" refers to the cryptographic technique underneath, and "electronic signature" to the legal act. For everyday purposes the distinction changes nothing. > [!WARNING] > A photo of your signature pasted into a document is not an electronic signature: it is an image. Anyone can copy it into another document. **Is it worth the same as signing by hand?** Under the European framework an electronic signature cannot be rejected merely for being electronic. What decides its strength is the evidence behind it. **Do I need a digital certificate?** It depends on the level required. For most commercial documents, no. **Does an email saying "agreed" count?** It may count as acceptance, but it proves far less: it does not pin down which version of the document was accepted. ## Ejemplos **A client asks whether they can sign the contract "properly" instead of electronically.** - Has it explained what gets recorded when signing - Signs from their phone → The contract ends up with more evidence than it would have had on paper, where nobody records when it was signed. **A supplier says their scanned signature in the PDF is already an electronic signature.** - Explains what is recorded in each case → A pasted image is distinguished from an act with proof behind it. **Somebody signs from a phone on a train and doubts it counts.** - Checks the evidence that was stored → The device does not change what can be demonstrated. **A company wants to know what proof it holds if the signer denies it.** - Opens the signed copy and its evidence record → The answer sits inside the document itself. **A paper signature is given and nobody notes the day.** - Signs electronically and leaves the time recorded → The date stops being the first thing argued about. **A signer asks for a copy after signing.** - Sends them the signed document with its evidence → Both parties hold the same thing. --- --- id: KB-GL-004 url: https://app.codecontract.io/help/glossary/what-is-a-qualified-signature idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-003, KB-CO-009] citadoPor: [KB-GL-003] --- # What is a qualified signature _The highest level of electronic signature, and when it is genuinely required._ **Responde a:** what is a qualified signature · difference between simple advanced and qualified signature · when is a qualified signature required · qualified signature certificate **Qualified electronic signature** — One made with a certificate issued by a qualified provider and a secure signature creation device. In the European framework it is the only one legally equivalent to a handwritten signature. ## The three levels | Level | What it requires | Used for | | --- | --- | --- | | Simple | Little beyond acceptance | Internal approvals, acknowledgements | | Advanced | Identifying the signer and detecting changes to the document | Most commercial contracts | | Qualified | A qualified certificate and secure device | Whatever the law expressly requires | Most day-to-day work is handled by a well-executed advanced signature. Qualified adds real friction — the signer needs their certificate — and only pays off when it is required. > [!IMPORTANT] > If a specific document requires a qualified signature, the rule governing it says so, not the platform. Ask your adviser before deciding on your own judgement: getting this wrong invalidates the whole document. > [!WARNING] > Raising the level "just in case" has a cost: every signer without a certificate is locked out, and the document goes unsigned. **Do I need qualified for a supplier contract?** Usually not. Advanced is the norm. **Does a national eID work?** It is a qualified certificate, yes, if the signer can use it. **What about outside the EU?** Qualified is a European concept. Other countries have their own schemes. ## Ejemplos **A company wants qualified signatures on every contract.** - Checks which documents genuinely require it - Keeps qualified only for those → The rest are signed same-day instead of waiting for every supplier to obtain a certificate. **A client demands a qualified signature and the supplier has no certificate.** - Checks whether that document really requires one → The requirement applies where it is needed rather than by habit. **A process stalls because three signers cannot obtain their certificate.** - Separates the documents that require it from those that do not → What can move, moves, while the rest is sorted out. **Nobody knows what it adds over an ordinary signature.** - Compares what proof each level leaves → The decision rests on the real difference rather than the name. **A document is signed with a certificate and the resulting file cannot be validated.** - Keeps the document exactly as it was signed → Later validation works because nothing has been saved over it. **A foreign signer holds a certificate from another country.** - Checks with the adviser whether it serves that use → The question is settled before the document goes out. --- --- id: KB-GL-005 url: https://app.codecontract.io/help/glossary/what-is-a-timestamp idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-002, KB-GL-006, KB-GL-008] citadoPor: [KB-SC-006, KB-SC-007, KB-TZ-008, KB-GL-015, KB-GL-006] --- # What is a timestamp _A date not set by whoever signed, which is why it counts._ **Responde a:** what is a timestamp · what a document timestamp is for · timestamping authority · how to prove a document's date **Timestamp** — Certification, issued by an independent third party, that a specific document existed exactly as it stands at a given instant. The value sits in "independent third party". If the date were set by whoever stores the document, you would have to trust them. Set by an authority outside both parties, the date stands on its own. ## What it certifies and what it does not | Certifies | Does not certify | | --- | --- | | That this document existed on that date | That what it says is true | | That it has not changed since | Who wrote it | | That the time came from a third party | That it was lawful | > [!NOTE] > It is the difference between saying "I had this in March" and being able to prove it. In a dispute, the first is your word and the second admits no reply. > [!WARNING] > The seal covers the exact file. Reprint it or convert it and the file changes, so the seal no longer matches — correctly. **Does it expire?** The date certification does not expire. What ages are the algorithms, which is why long-retention documents get re-sealed. **Can I check it myself?** Yes, with no account, on the public verification page. **Can something old be sealed?** Yes, but the certified date is today's, not the original. ## Ejemplos **A studio wants to prove a design was theirs before a client meeting.** - Seals the design the day it is finished → When a similar product appears months later, the date does not rest on their word. **Two parties argue over which of two versions came first.** - Checks the timestamp on each → The order is set by a third party rather than by memory. **A company saves a file and trusts the system's modified date.** - Timestamps the document when it is finished → The date can no longer change when the file is copied. **You want to prove a report existed before a meeting.** - Timestamps the report the day it is closed → The proof does not rest on emails or diaries. **A client doubts the annex they received is the one that was sealed.** - Compares the annex's fingerprint with the registered one → The doubt is settled in seconds without argument. **A document is sealed and afterwards a typo is corrected.** - Seals the corrected version too → Both versions carry their own date and are distinguishable. --- --- id: KB-GL-006 url: https://app.codecontract.io/help/glossary/what-is-a-document-hash idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-005, KB-TZ-002] citadoPor: [KB-GL-005] --- # What is a document fingerprint _A short number that changes if a single comma in the document changes._ **Responde a:** what is a file hash · document digital fingerprint · how to tell if a pdf was modified · sha256 document **Hash (fingerprint)** — A short value calculated from a file's entire content, such that any change to the file — however small — produces a completely different value. It is what lets you check a document has not changed without keeping a copy to compare against. Storing the fingerprint, a few dozen characters, is enough. ## The three properties that make it useful **En corto** - The same file always yields the same fingerprint. - Changing one comma yields a completely different fingerprint, not a similar one. - The document cannot be reconstructed from the fingerprint. The third matters more than it seems: you can publish the fingerprint of a confidential contract without revealing anything about its content, and still prove later that it is the same contract. > [!NOTE] > When verification says "does not match", it is almost never fraud: reprinting a PDF, re-saving it from another program or converting it changes the file. Change the file, change the fingerprint. **Can two different documents share a fingerprint?** With the algorithms in use, not in practice. **Does the fingerprint say what changed?** No, only that something changed. To know what, compare the two versions. **Do I need to understand this to use it?** No. Verification tells you "matches" or "does not match". ## Ejemplos **Two parties want a record of a confidential agreement without showing it to anyone.** - Seal the document - Share only the fingerprint with a third party → They can later prove the agreement is exactly that one, without having revealed its content. **Somebody forwards a document and it must be established it is the same one.** - Compares the received fingerprint with the registered one → The check does not require reading it through. **A comma is changed in an already sealed contract.** - Checks that the fingerprint no longer matches → Any change is detected, however small. **Two copies look identical and one has been altered.** - Computes the fingerprint of both → The original is identified without opening a dispute. **A document's existence must be proved without disclosing it.** - Shares only its fingerprint → The proof travels without the content. **A third party wants to verify a document that reached them another way.** - Tells them how to check the fingerprint themselves → Verification does not require trusting whoever sent it. --- --- id: KB-GL-007 url: https://app.codecontract.io/help/glossary/what-is-signing-evidence idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-005, KB-CO-009] citadoPor: [KB-GL-008] --- # What is signing evidence _The record that travels inside the signed document and makes it defensible._ **Responde a:** what is signature evidence · electronic signature audit trail · what information is stored when signing · how to prove someone signed **Signing evidence** — The set of data recorded during the signing process — sending, opening, identification and signature — that later allows what happened, and when, to be reconstructed. The signature itself is an instant. The evidence is the path that led to that instant, and it is what answers when someone says "I never signed that". ## What gets recorded | Moment | What is kept | | --- | --- | | Sending | Who it went to, on which channel and when | | Delivery | Whether it arrived or bounced | | Opening | When it was opened and from what kind of device | | Identification | How identity was checked: phone code, certificate, email | | Signature | The exact instant, with a certified time | None of those items proves much on its own. Together and in sequence, they force anyone disputing it to explain how all of that happened without them. > [!IMPORTANT] > The evidence travels inside the signed copy. If someone sends you only the PDF printed and rescanned, they have lost the evidence: what you hold is a piece of paper that looks like a contract. **Is my exact location stored?** Technical access information is recorded, not tracking of the person. **Can the signer see their own evidence?** Yes, it travels in the copy they receive. **Does it hold up in court?** It is precisely the material a signature is defended with. Its specific weight is for a judge to assess. ## Ejemplos **A signer denies, two years later, having accepted a clause.** - The signed copy and its evidence are opened → The record shows the code sent to their phone, the opening from that same device and the certified signing time. **A signer says they never received the document.** - Checks the send and open evidence → It is on record when it was delivered and when it was opened. **A signature is requested in a procedure and the detail is needed.** - Provides the signed document with its evidence → A complete item is handed over rather than a screenshot. **Somebody signs from a device other than their usual one.** - It is recorded where it was opened and signed from → The anomaly can be explained rather than suspected. **Only the final PDF is kept and the context is lost.** - Keeps the document with its associated evidence → The proof is not separated from the document it backs. **A client asks exactly what is stored about them when signing.** - Shows them which fields make up the evidence → The answer is specific and verifiable. --- --- id: KB-GL-008 url: https://app.codecontract.io/help/glossary/what-is-a-one-time-code idioma: en categoria: glosario subcategoria: firma audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-CO-006, KB-GL-007] citadoPor: [KB-GL-005] --- # What is the code sent to your phone _The most common second factor when signing, and why it adds so much._ **Responde a:** what is a one-time code · what is the code sent when signing for · the one-time code is not arriving · sms verification when signing **One-time code** — A short number, valid for a few minutes and only once, sent to a channel only the signer controls — usually their phone — to check they are who they claim to be. It does the same job as asking for ID at a counter: checking that the person in front of you is who they say. Only here, what is checked is access to a specific phone number. ## Why it adds so much **En corto** - An email can be read by anyone with access to that inbox. - The code additionally requires holding the phone. - It expires in minutes, so an old one is useless. It is the difference between "someone with access to this inbox accepted" and "the person holding this phone accepted". In a dispute, the second sentence is far harder to argue with. > [!WARNING] > Never share that code with anyone, not even whoever sent you the document. No legitimate party will ask for it by phone: the code is yours and is typed into the screen, not dictated. > [!NOTE] > If it does not arrive, request another. Requesting another does not invalidate the document or force you to start again. **How long does it last?** A few minutes. After that you request a new one. **Does receiving it cost anything?** Not for the signer. **What if I no longer have that number?** Tell whoever sent the document so they can update the contact. ## Ejemplos **Someone receives a call asking for the code that just arrived on their phone.** - Does not give it - Warns the company that sent the document → Prevents a third party signing in their name; the code was the only piece the caller was missing. **A signer does not receive the code and cannot sign.** - Checks the registered number and resends → The blockage clears without changing the document. **The code is shared with a colleague so they can sign instead.** - Explains the signature will stand in the name of whoever received the code → Each signature still points to one specific person. **A mobile number is mistyped in the contact record.** - Corrects the contact before resending the request → The code reaches whoever has to sign. **Somebody phones asking for the code, posing as support.** - It is not given and whoever sent the document is alerted → An attempt to sign in someone else's name is stopped. **A signer with no signal cannot receive the message.** - Agrees another verification route with whoever sent it → The signature is resolved without giving up the second factor. --- --- id: KB-GL-009 url: https://app.codecontract.io/help/glossary/what-is-ocr idioma: en categoria: glosario subcategoria: documentos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-GL-010] citadoPor: [KB-GL-020] --- # What is OCR _Turning a picture of text into text that can be searched and read._ **Responde a:** what is ocr · optical character recognition · how a scanned pdf is read · search inside scanned documents **OCR** — Optical character recognition: the technique that looks at the image of a page and recognises which letters and numbers are on it, turning it into text. A scanned PDF is a photograph of a piece of paper: to a computer, pixels. OCR is what turns those pixels into words, and it is what then allows searching inside it or extracting a date from it. ## Why it sometimes fails | Original | How well it is recognised | | --- | --- | | Computer-generated PDF | Perfectly: the text is already inside | | 300 dpi scan, straight | Very well | | Phone photo, in good light | Well | | Crooked or shadowed photo | Patchy or badly | | Handwriting | Badly, and that is expected | > [!WARNING] > What you cannot read at a glance, OCR cannot either. If you hesitate looking at the document, do not expect it to come out well. > [!NOTE] > A PDF that already carries text does not need OCR, which is why it reads perfectly. Asking for PDFs instead of photos is the cheapest way to improve reading. **Does OCR change my document?** No. The original is stored as is; the recognised text is kept separately. **Does it work in other languages?** Yes, including non-Latin scripts. **Can misreadings be corrected?** Yes, and the correction improves reading for that document type. ## Ejemplos **A company cannot find anything inside its old scans.** - Checks they were uploaded without reading - Reprocesses them → They become searchable by content, not just by filename. **A photo of a delivery note does not allow searching by order number.** - Checks it was processed on upload → The number is found without opening the image. **A skewed, shadowed scan reads badly.** - Retakes the capture with better light and framing → Reading improves without changing anything in the system. **A handwritten document does not read well.** - Reviews by hand whatever is flagged as uncertain → You correct the little that fails instead of keying it all. **A PDF already contained text and is processed again.** - Checks whether the document was already searchable → You avoid spending on something that was not needed. **There are hundreds of unprocessed old scans.** - Processes first the ones actually consulted → Effort concentrates on what somebody will look for. --- --- id: KB-GL-010 url: https://app.codecontract.io/help/glossary/what-is-the-confidence-score idioma: en categoria: glosario subcategoria: documentos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-DI-004, KB-DI-005] citadoPor: [KB-DI-009, KB-GL-016, KB-GL-009] --- # What is the confidence indicator _How sure the system is about each value it read, and what to do with that._ **Responde a:** what does confidence on an extracted value mean · low confidence on a document · when to review extracted data · ocr confidence percentage **Confidence indicator** — A measure of how sure the system is that it read a particular value correctly, based on the clarity of the original and on what is plausible for that field. It is what makes automatic reading usable. Without it you would review everything just in case; with it you review what asks to be reviewed. ## How to read it | Level | What it means | What to do | | --- | --- | --- | | High | The value was read clearly | Use it | | Medium | It was read, but something does not quite fit | A glance | | Low | The original did not allow a clean read | Check it against the document | > [!IMPORTANT] > A low-confidence value must not be used for anything with consequences — a payment, an official registration, an access decision — without being checked. Automatic reading saves time; responsibility stays with whoever decides. > [!NOTE] > If one document type always comes back low, the problem is how it arrives: ask for a better-quality original rather than reviewing each one by hand. **Does confidence say whether the value is correct?** It says whether it was read correctly, not whether the paper tells the truth. **Can I filter by low confidence?** Yes, and it is the efficient way to review a large batch. **Does it rise if I correct it?** Correcting improves reading of subsequent documents of the same type. ## Ejemplos **A batch of two hundred certificates arrives for review.** - Filters by low confidence - Reviews the eighteen that come up → Review goes from a full day to half an hour, without giving up on checking what is doubtful. **Everything is reviewed equally even though almost all of it read well.** - Sorts by confidence and starts at the bottom → Review time concentrates where the risk is. **A high-confidence figure turns out to be wrong.** - Corrects the figure and records the correction → The indicator guides, but the last word stays human. **Nobody knows what threshold to review at.** - Tries a real batch and adjusts → The threshold is set from your own data rather than a default. **One document type always comes out with low confidence.** - Checks whether the extraction model fits that format → The problem is tackled at source rather than at every review. **Two hundred figures are approved in bulk without looking.** - Sets the uncertain ones aside before approving the rest → Bulk approval stops dragging along what was failing. --- --- id: KB-GL-011 url: https://app.codecontract.io/help/glossary/what-is-a-case idioma: en categoria: glosario subcategoria: procesos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TL-001, KB-GL-012] citadoPor: [KB-TL-014, KB-GL-018, KB-GL-019, KB-GL-012] --- # What is a case _Everything to be gathered about one matter, together and with its dates._ **Responde a:** what is a case in trackline · difference between case and process · what is a documentation folder · how supplier documentation is organised **Case** — The unit of work grouping everything about one specific matter: what was asked for, from whom, what arrived, when, and what state it is in. It is the familiar folder, with two differences that matter: it knows what is missing, and it knows when each item arrived. ## Case, process and template | Word | What it is | Example | | --- | --- | --- | | Template or schema | The mould: what is always asked for | "Supplier onboarding" | | Case | One specific instance from that mould | "Onboarding Muñoz Engineering" | | Phase | A block of requests inside the case | "Company documentation" | Confusing template with case is the commonest organisational mistake: a template gets created per supplier, and what made templates useful is exactly what is lost. > [!NOTE] > A case can have several participants, and each sees only their own part. That is what lets you ask two competing subcontractors for documents without them seeing each other. **Does a case close?** Yes, when it is complete or when it is decided it will not progress. **Can it hold documents I did not request?** Yes, they can be added without having been a request. **Can it be reopened?** Yes. ## Ejemplos **A company creates a new template for every supplier it onboards.** - Keeps a single "Supplier onboarding" template - Each supplier becomes a case → The process can be improved in one place and every future onboarding benefits. **A new file is opened for every document that arrives.** - Groups everything on the same matter into one file → The matter is seen whole rather than in pieces. **A file is closed with a document still missing.** - Checks what is outstanding before closing it → Closing means the same thing to the whole team. **Nobody knows where a matter stands without asking.** - Checks the file's status → The answer does not depend on who you ask. **Two people request the same thing from the same supplier.** - Works on the shared file → The supplier receives one request, not two. **Months later somebody must explain how a matter was resolved.** - Opens the file with its complete history → The explanation comes from the file itself. --- --- id: KB-GL-012 url: https://app.codecontract.io/help/glossary/what-is-a-phase idioma: en categoria: glosario subcategoria: procesos audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-GL-011, KB-TL-006] citadoPor: [KB-GL-018, KB-GL-011] --- # What is a phase _Splitting what you ask for into blocks, which is what most raises delivery._ **Responde a:** what is a phase in a process · why split into phases · why am i not asked for everything at once · order of phases in a case **Phase** — A block of requests that open together inside a case. The next opens when the previous one is complete. It is not organisational decoration: it is the reason people deliver. Twelve requests at once get left for later; four blocks of three get worked through. ## How to split them well **En corto** - Into blocks that make sense to whoever delivers, not to you. - Three to six requests per phase. - Whatever blocks you, in the first one. "Company documentation", "people documentation", "machinery documentation" are meaningful phases. "Phase 1", "Phase 2" and "Phase 3" say nothing to whoever receives them. > [!WARNING] > Chaining too many phases lengthens the process: each waits for the previous. Three or four is usually the useful limit. > [!NOTE] > If everything you ask for can be delivered at once and there are no real dependencies, one phase is correct. Phases serve where there is an order, not always. **Can a phase be opened early?** Yes, if you need that part urgently. **Does the participant know about later phases?** They see their own. Phases not yet opened do not appear to them. **Can a phase be added while the case runs?** Yes. ## Ejemplos **An onboarding asks for eleven documents in one phase and has been open three weeks.** - Splits them into three named phases → The next subcontractor delivers all six mandatory items in four days. **Fifteen documents are requested at once and none arrives.** - Splits into phases and starts with the essentials → The first phase completes and the rest follows behind. **One phase depends on another finishing and nobody knows.** - Orders phases by what actually depends on what → The supplier does not receive requests they cannot yet meet. **All phases open at once and the supplier gets lost.** - Opens the next one as the previous closes → Each moment has a short, clear list. **A phase stalls and nobody notices.** - Lets it flag when a phase has been open too long → The blockage surfaces without being hunted. **Phases are called «phase 1» and «phase 2».** - Names them after what each one asks for → The supplier understands what is due without opening anything. --- --- id: KB-GL-013 url: https://app.codecontract.io/help/glossary/what-is-personal-data idioma: en categoria: glosario subcategoria: cumplimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-TZ-003, KB-MA-003] citadoPor: [KB-CS-012, KB-CS-022, KB-LE-003, KB-GL-017, KB-DI-019, KB-TZ-006] --- # What counts as personal data _More things than you would think, which is why who can see them matters._ **Responde a:** what is personal data gdpr · is an id number personal data · can i store an employee's phone number · suppliers' personal data **Personal data** — Any information that allows a specific person to be identified, directly or by combining it with something else. Not only their name and ID number. The list is longer than people assume, and it is the reason that inside a platform like this you have to think about who sees what. ## Things that count and get forgotten | Item | Personal data? | | --- | --- | | Name, identity document | Yes, obviously | | Work email and phone | Yes | | Bank account number | Yes | | A vehicle registration | Yes, if it leads to the person | | A worker's training certificate | Yes, it is in their name | | A company's tax number | No, that belongs to the company | > [!IMPORTANT] > Health data, data about minors and data on convictions carry heightened protection. If you will handle them — a medical check, training for a minor on placement — do not treat it as just another document: decide expressly who may see it. ## The rule that settles most of it Ask for the minimum you need for what you are doing, keep it as long as necessary and no longer, and let only the people who must see it see it. That covers most day-to-day situations. > [!WARNING] > This is not legal advice. The specifics of your situation come from your adviser or data protection officer. **Can I ask a supplier for an ID document?** If you need it for what you are doing, yes. If not, better not to hold it. **What about a copy of a driving licence?** Only if the role or service requires it. **Does keeping less leave me less covered?** No. Keeping what you do not need is risk with no upside. ## Ejemplos **A company keeps ID copies for every candidate it interviews.** - Decides to keep only those of people who join - Applies the rule to the existing backlog → It stops holding hundreds of identity documents it had no reason to hold. **An identity document is stored without knowing why it is needed.** - Reviews what justifies keeping it and for how long → What is kept has a reason and a period. **The whole team can open documentation containing sensitive data.** - Limits who sees what according to their work → Access stops being a matter of general trust. **A whole file is shared when only one document was needed.** - Shares only what is relevant → What was asked for is handed over, and nothing more. **A candidate asks for their data to be deleted.** - Locates where it sits and acts on the policy → The request is handled without searching everywhere. **Nobody knows how long each document type is kept.** - Sets a retention policy and applies it → The decision is taken once and stops being improvised. --- --- id: KB-GL-014 url: https://app.codecontract.io/help/glossary/what-is-an-audit-trail idioma: en categoria: glosario subcategoria: cumplimiento audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-AD-004, KB-CF-003] citadoPor: [KB-GL-017, KB-TZ-004, KB-TZ-005] --- # What is an audit trail _The record of who did what and when, which cannot be rewritten._ **Responde a:** what is an audit trail · audit trail meaning · tamper-evident action log · user action traceability **Audit trail** — The sequential record of actions taken on a system — who, what, when — stored so that it cannot be altered afterwards. What makes it worth something is that last part. A log the administrator could retouch would prove nothing, because the administrator is precisely who would have reason to retouch it. ## What it is for, in practice | Situation | What it answers | | --- | --- | | An external audit | That controls were genuinely applied, not just written down | | A dispute | What was done, in what order and when | | Improper access | Who signed in, from where and what they looked at | | An internal error | What changed and who changed it | > [!IMPORTANT] > Once a dispute is live, do not reorganise or modify what it touches. Everything is logged, and a change made after the dispute always reads in the worst possible way, however innocent. > [!NOTE] > An audit trail is no substitute for looking at it. It always exists; the value appears when someone reviews it occasionally, or when something has to be answered. **Can an entry be deleted?** No. That is what makes it useful. **How long is it kept?** According to your retention policy. **Can everyone see it?** No. It is sensitive information about the people on your team. ## Ejemplos **An auditor asks how you guarantee documentation was checked before granting site access.** - Is shown the audit trail of several cases → They see approvals with their author and time, and the control stops being a claim and becomes evidence. **Somebody claims they reviewed a document and there is no record.** - Checks that file's audit trail → What was done has an author and a time. **You want to know who granted a third party access.** - Looks up the action in the log → Granting access stops being anonymous. **A figure appears changed and nobody knows who touched it.** - Checks the figure's own history → The change has a date and someone responsible. **An auditor asks for evidence of a control, not its description.** - Shows them the log of several real operations → The control moves from assertion to evidence. **There is concern that someone could rewrite the log.** - Verifies that entries cannot be edited → The log's value lies in nobody being able to correct it afterwards. --- --- id: KB-GL-001 url: https://app.codecontract.io/help/glossary/glossary-of-terms idioma: en categoria: glosario audiencia: usuario actualizado: 2026-08-13 tambienEn: [es] relacionados: [KB-PS-002, KB-TL-001, KB-ET-002] citadoPor: [KB-GL-015, KB-PS-004, KB-GL-002] --- # Glossary: what each word means _The terms used across the platform, each explained in a single line._ **Responde a:** what is a case in code contract · difference between a schema and a process · what is an external participant · glossary of platform terms · what does certified evidence mean Almost every confusion in the first days is about vocabulary, not about how things work. These are the words worth getting straight, in the order you tend to meet them. ## How information is organised **Folder** — A container for tidiness. It nests and it is optional. **Project** — The unit of work. It does not nest, it belongs to one module, and every document lives inside one. **Document** — The file itself: what people send you, what gets signed, or what you certify. **Data** — The fields taken from a document: amount, date, number. Automatic reading proposes them and you confirm. ## Trackline **Schema or process** — The template: what is asked for, in what order and from whom. Designed once. **Case** — One specific run of a schema. One per supplier, client or matter. **Phase** — A block of requests that go out together. The next opens when the previous is complete. **Request** — Each thing you ask for: a document, some data, or both together. ## People **User** — Someone in your organisation, with an account and a password. Uses a licence. **External participant** — Someone outside — supplier, client, signer. Opens a link, has no account, uses no licence. **Contact** — A person's record in your address book, with their email, mobile and language. ## Consigne **Simple signature** — The signer draws their signature. When and from where is recorded. **Advanced signature** — The same, plus confirming a code sent to their mobile by SMS. **Evidence chain** — The full account of a signature: who, when, how and from where. **Timestamp** — The independent certification of when it was signed, which stops the date being arguable. ## SmartCheck and traceability **Evidence** — Something certified: a file or some data, sealed with a demonstrable date. **Fingerprint** — The unique summary of a file. It changes completely if one character is altered, which is how tampering is detected. **Public verification** — The page where anyone can check a document without an account and without your permission. **Audit dossier** — The export of a whole folder with its evidence and dates. ## Platform **Credits** — The unit used to pay for actions with an external cost: AI reading, SMS, sealing. **Organisation** — Your company inside the platform. Each one's data is kept separate. **Audit log** — The immutable history of who did what and when. **Error code** — The identifier shaped E-YYMMDD-XXXX shown when something fails. It lets support find the exact problem. ## Ejemplos **Someone new to the team tries to create accounts for suppliers as users and runs out of licences.** - Reads the difference between a user and an external participant - Discovers the supplier needs no account - Cancels the invitations and runs the process with links instead → The licences are free again and the suppliers deliver just the same, registering for nothing. **Two departments use «file» to mean different things.** - Settle the vocabulary with the glossary → Meetings stop starting by clarifying terms. **An internal email mentions «batch» and nobody knows if it means purchasing or production.** - Checks the definition before replying → The answer addresses what was actually asked. **A newcomer does not understand the difference between phase and file.** - Reads the two entries in sequence → They start working without needing a training session. **A supplier asks what a term in the notice means.** - Links them the specific glossary entry → The clarification is a line rather than a phone call. **An internal procedure is written using invented terms.** - Uses the same names as the platform → The procedure and the tool say the same thing. --- --- id: KB-GL-002 url: https://app.codecontract.io/help/glossary/the-words-in-our-notices idioma: en categoria: glosario audiencia: usuario nivel: intermedio actualizado: 2026-08-13 tambienEn: [es, de, zh, fr, pt] relacionados: [KB-GL-001, KB-PS-004] citadoPor: [KB-CO-013, KB-PS-007] --- # The words you will see in a notice _What each term means if you received one of our emails and are not a customer._ **Responde a:** what is a code contract case · what does pending request mean · they are asking me for documents what is this · what is a phase in a process If you have landed here it is probably because you received an email asking you for something and want to know what each word means before clicking anything. That is sensible. Here is what they mean. **Case** — Everything that has to be gathered about one matter: your documents, who asked for them and when they arrived. A folder, digitally. **Request** — One specific thing you are being asked for. A case holds several. **Phase** — A block of requests that go together. The next opens when the previous finishes, so you are not asked twelve things at once. **Participant** — Each person being asked for something. You are one of them. **Mandatory** — Without it, the matter cannot proceed. Anything not marked so can be left if you do not have it. **Signer** — Whoever has to sign a document. No account is needed to be one. **Evidence** — The record of when you opened it, how your identity was checked and when you signed. It travels inside your copy. **Seal** — A mark that lets anyone check later that the document has not changed since. **Expiry** — The date from which a document stops counting and a new one is needed. > [!WARNING] > None of these words implies you have agreed to anything. Receiving a request does not oblige you: you can read what is being asked and decide. > [!NOTE] > If the email you received does not add up — you do not know the sender, or you were expecting nothing — do not click and ask the company directly through a channel you already knew. **Do I have to register to reply?** No. The link takes you straight to your part. **Can other companies see my documents?** No. Only whoever asked you for them. **Can I tell who is asking?** Yes, it appears in the notice itself and on the page the link opens. ## Ejemplos **A self-employed contractor gets an email from a builder asking for "the phase 1 documentation".** - Checks here what a phase is - Understands it is three documents, not the whole file → Replies the same day instead of leaving it because they did not know what it meant. **A notice mentions «file» and the recipient thinks it means court proceedings.** - Looks the term up on this page → It becomes clear it means everything being requested of them. **Somebody receives a request and does not know whether it is mandatory.** - Checks what the notice's statuses mean → They tell required from optional without asking. **A sole trader fears being asked to register for something.** - Checks the difference between participant and user → They reply through the link without registering. **The notice mentions «validity» and the recipient does not know which date to check.** - Looks up the term and checks their document → They send a valid document first time. **A reminder arrives and it seems everything was already sent.** - Checks what an open phase means → They see exactly what is missing instead of resending everything.